老生常谈JVM的内存溢出说明及参数调整
第一类内存溢出，也是大家认为最多，第一反应认为是的内存溢出，就是堆栈溢出：
那什么样的情况就是堆栈溢出呢？当你看到下面的关键字的时候它就是堆栈溢出了：
java.lang.OutOfMemoryError:......javaheapspace.....
也就是当你看到heap相关的时候就肯定是堆栈溢出了，此时如果代码没有问题的情况下，适当调整-Xmx和-Xms是可以避免的，不过一定是代码没有问题的前提，为什么会溢出呢，要么代码有问题，要么访问量太多并且每个访问的时间太长或者数据太多，导致数据释放不掉，因为垃圾回收器是要找到那些是垃圾才能回收，这里它不会认为这些东西是垃圾，自然不会去回收了；主意这个溢出之前，可能系统会提前先报错关键字为：
java.lang.OutOfMemoryError:GCoverheadlimitexceeded
这种情况是当系统处于高频的GC状态，而且回收的效果依然不佳的情况，就会开始报这个错误，这种情况一般是产生了很多不可以被释放的对象，有可能是引用使用不当导致，或申请大对象导致，但是javaheapspace的内存溢出有可能提前不会报这个错误，也就是可能内存就直接不够导致，而不是高频GC.
第二类内存溢出，PermGen的溢出，或者PermGen满了的提示，你会看到这样的关键字：
关键信息为:
java.lang.OutOfMemoryError:PermGenspace
原因：系统的代码非常多或引用的第三方包非常多、或代码中使用了大量的常量、或通过intern注入常量、或者通过动态代码加载等方法，导致常量池的膨胀，虽然JDK1.5以后可以通过设置对永久带进行回收，但是我们希望的是这个地方是不做GC的，它够用就行，所以一般情况下今年少做类似的操作，所以在面对这种情况常用的手段是：增加-XX:PermSize和-XX:MaxPermSize的大小。
第三类内存溢出：在使用ByteBuffer中的allocateDirect()的时候会用到，很多javaNIO的框架中被封装为其他的方法
溢出关键字：
java.lang.OutOfMemoryError:Directbuffermemory
如果你在直接或间接使用了ByteBuffer中的allocateDirect方法的时候，而不做clear的时候就会出现类似的问题，常规的引用程序IO输出存在一个内核态与用户态的转换过程，也就是对应直接内存与非直接内存，如果常规的应用程序你要将一个文件的内容输出到客户端需要通过OS的直接内存转换拷贝到程序的非直接内存（也就是heap中），然后再输出到直接内存由操作系统发送出去，而直接内存就是由OS和应用程序共同管理的，而非直接内存可以直接由应用程序自己控制的内存，jvm垃圾回收不会回收掉直接内存这部分的内存，所以要注意了哦。
如果经常有类似的操作，可以考虑设置参数：-XX:MaxDirectMemorySize
第四类内存溢出错误：
溢出关键字：
java.lang.StackOverflowError
这个参数直接说明一个内容，就是-Xss太小了，我们申请很多局部调用的栈针等内容是存放在用户当前所持有的线程中的，线程在jdk1.4以前默认是256K，1.5以后是1M，如果报这个错，只能说明-Xss设置得太小，当然有些厂商的JVM不是这个参数，本文仅仅针对HotspotVM而已；不过在有必要的情况下可以对系统做一些优化，使得-Xss的值是可用的。
第五类内存溢出错误：
溢出关键字：
java.lang.OutOfMemoryError:unabletocreatenewnativethread
上面第四种溢出错误，已经说明了线程的内存空间，其实线程基本只占用heap以外的内存区域，也就是这个错误说明除了heap以外的区域，无法为线程分配一块内存区域了，这个要么是内存本身就不够，要么heap的空间设置得太大了，导致了剩余的内存已经不多了，而由于线程本身要占用内存，所以就不够用了，说明了原因，如何去修改，不用我多说，你懂的。
第六类内存溢出：
溢出关键字
java.lang.OutOfMemoryError:request{}bytefor{}outofswap
这类错误一般是由于地址空间不够而导致。
六大类常见溢出已经说明JVM中99%的溢出情况，要逃出这些溢出情况非常困难，除非一些很怪异的故障问题会发生，比如由于物理内存的硬件问题，导致了codecache的错误（在由bytecode转换为nativecode的过程中出现，但是概率极低），这种情况内存会被直接crash掉，类似还有swap的频繁交互在部分系统中会导致系统直接被crash掉，OS地址空间不够的话，系统根本无法启动，呵呵；JNI的滥用也会导致一些本地内存无法释放的问题，所以尽量避开JNI；socket连接数据打开过多的socket也会报类似：IOException:Toomanyopenfiles等错误信息。
JNI就不用多说了，尽量少用，除非你的代码太牛B了，我无话可说，呵呵，这种内存如果没有在被调用的语言内部将内存释放掉（如C语言），那么在进程结束前这些内存永远释放不掉，解决办法只有一个就是将进程kill掉。
另外GC本身是需要内存空间的，因为在运算和中间数据转换过程中都需要有内存，所以你要保证GC的时候有足够的内存哦，如果没有的话GC的过程将会非常的缓慢。
顺便这里就提及一些新的CMSGC的内容和策略（有点乱，每次写都很乱，但是能看多少看多少吧）：
首先我再写一次一前博客中的已经写过的内容，就是很多参数没啥建议值，建议值是自己在现场根据实际情况科学计算和测试得到的综合效果，建议值没有绝对好的，而且默认值很多也是有问题的，因为不同的版本和厂商都有很大的区别，默认值没有永久都是一样的，就像-Xss参数的变化一样，要看到你当前的java程序heap的大致情况可以这样看看（以下参数是随便设置的，并不是什么默认值）：
$sudojmap-heap`pgrepjava`
AttachingtoprocessID4280,pleasewait...
Debuggerattachedsuccessfully.
Servercompilerdetected.
JVMversionis19.1-b02
usingthread-localobjectallocation.
ParallelGCwith8thread(s)
HeapConfiguration:
MinHeapFreeRatio=40
MaxHeapFreeRatio=70
MaxHeapSize=1073741824(1024.0MB)
NewSize=134217728(128.0MB)
MaxNewSize=134217728(128.0MB)
OldSize=5439488(5.1875MB)
NewRatio=2
SurvivorRatio=8
PermSize=134217728(128.0MB)
MaxPermSize=268435456(256.0MB)
HeapUsage:
PSYoungGeneration
EdenSpace:
capacity=85721088(81.75MB)
used=22481312(21.439849853515625MB)
free=63239776(60.310150146484375MB)
26.22611602876529%used
FromSpace:
capacity=24051712(22.9375MB)
used=478488(0.45632171630859375MB)
free=23573224(22.481178283691406MB)
1.9894134770946867%used
ToSpace:
capacity=24248320(23.125MB)
used=0(0.0MB)
free=24248320(23.125MB)
0.0%used
PSOldGeneration
capacity=939524096(896.0MB)
used=16343864(15.586723327636719MB)
free=923180232(880.4132766723633MB)
1.7395896571023124%used
PSPermGeneration
capacity=134217728(128.0MB)
used=48021344(45.796722412109375MB)
free=86196384(82.20327758789062MB)
35.77868938446045%used
付：sudo是需要拿到管理员权限，如果你的系统权限很大那么就不需要了，最后的grepjava那个内容如果不对，可以直接通过jps或者ps命令将和java相关的进程号直接写进去，如：java-map4280，这个参数其实完全可以通过jstat工具来替代，而且看到的效果更加好，这个参数在线上应用中，尽量少用（尤其是高并发的应用中），可能会触发JVM的bug，导致应用挂起；在jvm1.6u14后可以编写任意一段程序，然后在运行程序的时候，增加参数为：-XX:+PrintFlagsFinal来输出当前JVM中运行时的参数值，或者通过jinfo来查看，jinfo是非常强大的工具，可以对部分参数进行动态修改，当然内存相关的东西是不能修改的，只能增加一些不是很相关的参数，有关JVM的工具使用，后续文章中如果有机会我们再来探讨，不是本文的重点；补充：关于参数的默认值对不同的JVM版本、不同的厂商、运行于不同的环境（一般和位数有关系）默认值会有区别。