JVM调优、GC总结

• 内存分配
  http://blog.csdn.net/shimiso/article/details/8595564 
  http://blog.csdn.net/OyangYujun/article/details/41173747

• 特殊的内存：非JVM规范的内存区域:直接内存
  直接内存并非虚拟机规范定义的数据区的一部分，也不是虚拟机运行时数据区的一部分。可是这部份内存也被频繁的使用，并且也可能致使OOM。
  在JDK1.4中新加入了NIO类，引入了一种基于通道与缓冲区的I/O方式。它可使用Native函数库直接分配堆外内存，而后经过一个存储在Java堆中的DirectByteBuffer对象做为这块内存的引用进行操做。这样能在一些场合中显著提升性能，由于避免了在Java堆和Native堆中来回复制数据。

• 内存模型
  http://www.cnblogs.com/nexiyi/p/java_memory_model_and_thread.html

判断对象是否存活通常有两种方式：
1. 引用计数：每一个对象有一个引用计数属性，新增一个引用时计数加1，引用释放时计数减1，计数为0时能够回收。此方法简单，没法解决对象相互循环引用的问题。
2. 可达性分析（Reachability Analysis）：从GC Roots开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证实此对象是不可用的。不可达对象。

JVM垃圾回收机制采用有向图方式来管理内存中的对象

• 对象在内存中的状态：可达状态、可恢复状态、不可达状态

  • 可达状态：对象被建立后，有一个以上的引用变量引用它时。
  • 可恢复状态：若是对象再也不有任何引用变量引用它，将先进入可恢复状态，此时不能从有向图顶点导航到该对象，系统垃圾回收机制准备回收内存，在回收以前系统将调用可恢复状态的对象的finalize方法进行资源清理，若finalize方法能让一个以上的变量引用此对象，则对象会再次变为可达状态，不然进入不可达状态。
  • 不可达状态：当对象全部联系都被切断，且finalize方法没有使该对象变成可达，则对象将永久失去引用。系统会进行回收。

• Java对对象的引用分4种：强引用、软引用、弱引用、虚引用。

  • 强引用：建立变量并引用；最经常使用；绝对不会被垃圾回收机制回收，即便内存很是紧张。
  • 软引用：SoftReference;当系统内存足够时不会被系统回收，当系统内存空间不足时，系统将会回收；经常使用于建立大量某类对象时作优化；
  • 弱引用：WeakReference；当系统垃圾回收时，无论系统内存够不够，总会回收该对象所占内存；
  • 虚引用：不可单独使用，通常配合引用队列使用；主要做用是跟踪对象被垃圾回收的状态，程序能够经过检查与虚引用关联的引用队列中是否已经包含指定虚引用，从而了解虚引用的对象是否即将被回收。

• Java经常使用调试工具和命令

  • 一、jps
    显示系统中全部Hotspot虚拟机进程。
    参数：
    -l ：输出主类全名。
    -v：输出虚拟机进程启动的jvm参数。
    -m：输出启动时传递给main函数的参数。
    -q：只输出LVMID，省略主类的名称。

  • 二、jinfo
    显示虚拟机的配置信息，可观察进程运行环境参数，包括Java System属性和JVM命令行参数。
    参数：
    -flag< name >: 打印指定Java虚拟机的参数值。
    -flag [+|-]< name >：设置或取消指定java虚拟机参数的布尔值。
    -flag < name >=< value >：设置指定java虚拟机的参数的值。
    示例：
    ➜ ~ jinfo 10565 
    ➜ ~ jinfo -flag CICompilerCount 10565
    ➜ ~ jinfo -flag +PrintGCDetails
    ➜ ~ jinfo -flag -PrintGCDetails 10532
    ➜ ~ jinfo -flag CMSInitiatingOccupancyFraction=80 10532

  • 三、jstack
    做用：
    显示虚拟机的线程栈信息，用于生成当前JVM的全部线程快照。
    参数：
    -F：当正常输出的请求不被响应时，强制输出线程堆栈。
    -l：除堆栈外，显示关于锁的附加信息。
    -m：若是调用到本地方法的话，能够显示C/C++的堆栈 
    命令格式:jstack [option] vmid。 示例：
    ➜ ~ jstack -F 10532
    ➜ ~ jstack -l 10532
    ➜ ~ jstack -m 10532

  • 四、jstat
    做用：
    实时显示本地或远程JVM进程中类装载、内存、垃圾收集、JIT编译等数据。
    参数：
    -class：监视类装载、卸载数量、总空间及类装载所耗费的时间。
    -gc：监听Java堆情况，包括Eden区、两个Survivor区、老年代、永久代等的容量，以用空间、GC时间合计等信息。
    -gccapacity：监视内容与-gc基本相同，但输出主要关注java堆各个区域使用到的最大和最小空间。
    -gcutil：监视内容与-gc基本相同，但输出主要关注已使用空间占总空间的百分比。
    -gccause：与-gcutil功能同样，可是会额外输出致使上一次GC产生的缘由。
    -gcnew：监视新生代GC情况。
    -gcnewcapacity：监视内同与-gcnew基本相同，输出主要关注使用到的最大和最小空间。
    -gcold：监视老年代GC状况。
    -gcoldcapacity：监视内同与-gcold基本相同，输出主要关注使用到的最大和最小空间。
    -gcpermcapacity：输出永久代使用到最大和最小空间。
    -compiler：输出JIT编译器编译过的方法、耗时等信息。
    -printcompilation：输出已经被JIT编译的方法。
    示例：
    ➜ ~ jstat -class 10532 
    ➜ ~ jstat -gc 10532
    ➜ ~ jstat -gccapacity 10532
    ➜ ~ jstat -gcutil 10532
    ➜ ~ jstat -gccause 10532
    ➜ ~ jstat -gcnew 10532
    ➜ ~ jstat -gcnewcapacity 10532
    ➜ ~ jstat -gcold 10532
    ➜ ~ jstat -gcoldcapacity 10532
    ➜ ~ jstat -compiler 10532
    ➜ ~ jstat -printcompilation 10532

  • 五、jmap、jhat
    做用：
    用于生成虚拟机的内存快照信息
    jhat用网页方式查看dump信息 
    参数：
    -dump：生成java堆转储快照。
    -heap：显示java堆详细信息(只在Linux/Solaris下有效)。
    -F：当虚拟机进程对-dump选项没有响应时，可以使用这个选项强制生成dump快照(只在linux/Solaris下有效)。
    -finalizerinfo：显示在F-Queue中等待Finalizer线程执行finalize方法的对象(只在Linux/Solaris下有效)。
    -histo：显示堆中对象统计信息。
    -permstat：以ClassLoader为统计口径显示永久代内存状态(只在Linux/Solaris下有效)。
    示例：
    ➜ ~ jmap -heap 10532
    ➜ ~ jmap -histo 10532 | more
    ➜ ~ jmap -F 10532 ➜ ~ jmap -finalizerinfo 10532

  • 六、jconsole
    做用：
    内置 Java 性能分析器，能够从命令行或在 GUI shell 中运行。可以使用 JConsole来监控 Java 应用程序性能和跟踪 Java 中的代码。

  • 七、gc相关术语
    S0C：S0区容量（S1区相同，略） 
    S0U：S0区已使用
    EC：E区容量
    EU：E区已使用
    OC：老年代容量
    OU：老年代已使用
    PC：Perm容量
    PU：Perm区已使用
    YGC：Young GC（Minor GC）次数
    YGCT：Young GC总耗时
    FGC：Full GC次数
    FGCT：Full GC总耗时
    GCT：GC总耗时

• jvm参数调优 各个参数意义
  http://www.cnblogs.com/andy-zhou/p/5327288.html
  http://www.cnblogs.com/edwardlauxh/archive/2010/04/25/1918603.html
  http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
  http://blog.csdn.net/rongbo_j/article/details/51107898

• GC算法
  http://www.cnblogs.com/ityouknow/p/5614961.html
  http://blog.csdn.net/lingzhm/article/details/47174391

• classloader 委派模型

• 类加载器产生泄露缘由总结。 
  一、永久代内存不足
  二、动态代理类生成大量类

• 定义自已的类加载器分为两步：
  一、继承java.lang.ClassLoader
  二、重写父类的findClass方法

  为何只重写findClass方法？由于JDK已经在loadClass方法中帮咱们实现了ClassLoader搜索类的算法，当在loadClass方法中搜索不到类时，loadClass方法就会调用findClass方法来搜索类，因此咱们只需重写该方法便可。如没有特殊的要求，通常不建议重写loadClass搜索类的算法。