stackoverflowerror,stackoverflowerror原因
java.lang.StackOverFlowError 怎么解决 具体点
Java常见的几种内存溢出及解决方法【情况一】：
java.lang.OutOfMemoryError:Javaheapspace：这种是java堆内存不够，一个原因是真不够（如递归的层数太多等），另一个原因是程序中有死循环；
如果是java堆内存不够的话，可以通过调整JVM下面的配置来解决：
-Xms3062m
-Xmx3062m
【情况二】
java.lang.OutOfMemoryError:GCoverheadlimitexceeded
【解释】：JDK6新增错误类型，当GC为释放很小空间占用大量时间时抛出；一般是因为堆太小，导致异常的原因，没有足够的内存。
【解决方案】：
1、查看系统是否有使用大内存的代码或死循环；
2、通过添加JVM配置，来限制使用内存：
-XX:-UseGCOverheadLimit
【情况三】：
java.lang.OutOfMemoryError:PermGenspace：这种是P区内存不够，可通过调整JVM的配置：
-XX:MaxPermSize=128m
-XXermSize=128m
【注】：
JVM的Perm区主要用于存放Class和Meta信息的,Class在被Loader时就会被放到PermGenspace，这个区域成为年老代，GC在主程序运行期间不会对年老区进行清理，默认是64M大小，当程序需要加载的对象比较多时，超过64M就会报这部分内存溢出了，需要加大内存分配，一般128m足够。
【情况四】：
java.lang.OutOfMemoryError:Directbuffermemory
调整-XX:MaxDirectMemorySize=参数，如添加JVM配置：
-XX:MaxDirectMemorySize=128m
【情况五】：
java.lang.OutOfMemoryError:unabletocreatenewnativethread
【原因】：Stack空间不足以创建额外的线程，要么是创建的线程过多，要么是Stack空间确实小了。
【解决】：由于JVM没有提供参数设置总的stack空间大小，但可以设置单个线程栈的大小；而系统的用户空间一共是3G，除了Text/Data/BSS/MemoryMapping几个段之外，Heap和Stack空间的总量有限，是此消彼长的。因此遇到这个错误，可以通过两个途径解决：1.通过-Xss启动参数减少单个线程栈大小，这样便能开更多线程（当然不能太小，太小会出现StackOverflowError）；2.通过-Xms-Xmx两参数减少Heap大小，将内存让给Stack（前提是保证Heap空间够用）。
【情况六】：
java.lang.StackOverflowError
【原因】：这也内存溢出错误的一种，即线程栈的溢出，要么是方法调用层次过多（比如存在无限递归调用），要么是线程栈太小。
【解决】：优化程序设计，减少方法调用层次；调整-Xss参数增加线程栈大小。
java 无终止递归调用 产生StackOverflowError的 实质 原因是什么
Java里面每个线程都有独立的、固定大小的栈空间， Java在解释执行的时候采用的是栈式的架构。 方法调用、方法内的局部变量都是在栈空间申请的。 空间的大小依赖于JDK版本，JDK1.6应该是512K，超过了这个空间就会产生StackOverFlow。 不断的递归会使栈空间不断增大导致溢出。
要注意：StackOverFlow是“栈”空间的溢出；
OutOfMemoryError是“堆”空间的溢出。
Java-java产生StackOverflowError的原因是什么
Java-java产生StackOverflowError的原因是内存耗尽了，一般是由于程序中有递归或者死循环导致，检查一下程序就好了。
alert报错stackoverflowerror原因
每一个JVM线程都拥有一个私有的JVM线程栈，用于存放当前线程的JVM栈帧（包括被调用函数的参数、局部变量和返回地址等）。如果某个线程的线程栈空间被耗尽，没有足够资源分配给新创建的栈帧，就会抛出java.lang.StackOverflowError错误。
引发StackOverFlowError的常见原因有以下几种：
·无限递归循环调用（最常见）。
·执行了大量方法，导致线程栈空间耗尽。
·方法内声明了海量的局部变量。
·native代码有栈上分配的逻辑，并且要求的内存还不小，比如java.net.SocketInputStream.read0会在栈上要求分配一个64KB的缓存（64位Linux）。
除了程序抛出StackOverflowError错误以外，还有两种定位栈溢出的方法：
·进程突然消失，但是留下了crash日志，可以检查crash日志里当前线程的stack范围，以及RSP寄存器的值。如果RSP寄存器的值超出这个stack范围，那就说明是栈溢出了。
·如果没有crash日志，那只能通过coredump进行分析。在进程运行前，先执行ulimit-cunlimited，当进程挂掉之后，会产生一个core.[pid]的文件，然后再通过jstack$JAVA_HOME/bin/javacore.[pid]来看输出的栈。如果正常输出了，那就可以看是否存在很长的调用栈的线程，当然还有可能没有正常输出的，因为jstack的这条从core文件抓栈的命令其实是基于ServiceabilityAgent实现的，而SA在某些版本里有Bug。
常见的解决方法包括以下几种：
·修复引发无限递归调用的异常代码，通过程序抛出的异常堆栈，找出不断重复的代码行，按图索骥，修复无限递归Bug。
·排查是否存在类之间的循环依赖。
·排查是否存在在一个类中对当前类进行实例化，并作为该类的实例变量。
·通过JVM启动参数-Xss增加线程栈内存空间，某些正常使用场景需要执行大量方法或包含大量局部变量，这时可以适当地提高线程栈空间限制，例如通过配置-Xss2m将线程栈空间调整为2mb。
日志组件 logbook 导致内存溢出StackOverflowError
线上日志里发现有StackOverflowError
是因为使用日志组件logbook，会默认配置一个PrimitiveJsonPropertyBodyFilter，这个Filter是用来隐藏一些access_token之类的敏感数据的。使用的方式是正则匹配。
正则匹配在规则比较复杂，匹配内容比较大时很容易StackOverflowError。
LogbookAutoConfiguration.java
BodyFilters.java
DefaultFilters.java 通过SPI加载BodyFilter
logbook-json-2.13.0.jar/META-INFO/services/org.zalando.logbook.BodyFilter
JsonBodyFilters.java
PrimitiveJsonPropertyBodyFilter.java
覆盖声明bodyFilter，移除这个Filter
这个StackOverflowError问题，还会导致另外一个问题，查看另外一篇 SpringBoot Filter Exception导致响应json额外追加了一段json 。