JVM调优

参考： http://www.cnblogs.com/andy-zhou/p/5327288.html
http://www.open-open.com/lib/view/open1482392048975.html G1垃圾回收知识
http://www.blogjava.net/BlueDavy/archive/2009/03/11/259230.html

jvm调优：

1. 检查年轻代、年老代、持久代（metaspace）、线程栈大小设置是否合理
   
   • 实时性要求高吞吐量要求低：可增加新生代的大小、减少年老代的大小，使更少的对象进入年老代，减小年老代Full GC时暂停的时间。
   • java5后线程栈默认大小是1M。有时为了增加线程的数量（可达到3000-5000），可适当减小线程栈大小。
2. 分析垃圾回收方法是否合理
   
   • 串行回收 在单CPU，或内存占用较小（100M以下）的情况下使用
   • 并行回收 在实时性要求低吞吐量要求高的情况下使用，缺点：FullGC暂停时间较长
   • 并发回收 在实时性要求高的情况下使用
   • Garbage Firest（G1）增量回收算法满足了高实时性要求
3. 线程监控
   
   • 热点分析 检查哪些方法占用大量CPU时间
4. 快照
   
   • 使用快照检查垃圾回收前后，垃圾对象是否充分回收。
5. 内存泄露
   
   • 检查是否有对象不能被回收，导致持久代不断增大，最终无法分配更多内存导致系统崩溃。
   • 解决办法：垃圾回收前后使用系统快照，并查看引用使用情况
     6 java.lang.OutOfMemoryError: PermGen space
   • 在使用了大量反射后，导致持久代被占满。更可怕的是不同的ClassLoader会重复加载同一个类。
   • 解决办法：1. -XX:MaxPermSize=16m。 2.换用JDK。比如JRocket。
     7 堆栈溢出 异常：java.lang.StackOverflowError
   • 说明：这个就不多说了，一般就是递归没返回，或者循环调用造成
6. 线程堆栈满 异常：Fatal: Stack size too small
   
   • 说明：java中一个线程的空间大小是有限制的。JDK5.0以后这个值是1M。与这个线程相关的数据将会保存在其中。但是当线程空间满了以后，将会出现上面异常。
   • 解决：增加线程栈大小。-Xss2m。但这个配置无法解决根本问题，还要看代码部分是否有造成泄漏的部分。
     9 系统内存被占满 异常：java.lang.OutOfMemoryError: unable to create new native thread
   • 说明：这个异常是由于操作系统没有足够的资源来产生这个线程造成的。系统创建线程时，除了要在Java堆中分配内存外，操作系统本身也需要分配资源来创建线程。因此，当线程数量大到一定程度以后，堆中或许还有空间，但是操作系统分配不出资源来了，就出现这个异常了。
     分配给Java虚拟机的内存愈多，系统剩余的资源就越少，因此，当系统内存固定时，分配给Java虚拟机的内存越多，那么，系统总共能够产生的线程也就越少，两者成反比的关系。同时，可以通过修改-Xss来减少分配给单个线程的空间，也可以增加系统总共内生产的线程数。
   • 解决：1. 重新设计系统减少线程数量。 2. 线程数量不能减少的情况下，通过-Xss减小单个线程大小。以便能生产更多的线程。

垃圾回收悖论

java垃圾回收为开发代来很多便利。但是在高并发、高实时条件下垃圾回收成了系统的瓶颈。现有的垃圾回收算法无法解决垃圾回收时的暂停问题，对系统性能带来很大影响。这也是后续JDK增加G1垃圾回收算法的重要原因。

JVM工具的使用

http://www.cnblogs.com/feng-gamer/p/6039380.html 使用VisualVM分析性能
http://zhouanya.blog.51cto.com/4944792/1370017/ Jvisualvm–JAVA性能分析工具