JVM笔记10-性能优化之高级特性
一.垃圾回收器配置和 GC 日志分析
1.堆典型配置：java
32位的操做系统限制堆大小介于1.5G到2G，64位操做系统无限制，同时系统可用虚拟内存和可用物理内存都会限制最大堆的配置。web
堆空间分配典型配置：面试
1.-Xms：初始堆大小算法
2.-Xmx：最大堆大小api
3.-XX:NewSize=n：设置年轻代大小缓存
4.-XX:NewRatio=n：设置年轻代和年老代的比值。如 n 为 2，表示年轻代与年老代比值为 1:2，年轻代占整个年轻代年老代和的 1/3服务器
5.-XX:SurvivorRatio=n：年轻代中 Eden 区与两个 Survivor 区的比值。注意 Survivor 区有两个。如 n 为 2，表示 Eden:Survivor=1:2，一个 Survivor 区占整个年轻代的 1/4并发
6.-XX:MaxMetaspaceSize=：设置最大化元空间大小app
7.XX：MetaspaceSize=64m 初始化元空间大小；负载均衡
8.-Xmn2g：设置年轻代大小为 2G。整个 JVM 内存大小 = 年轻代大小 + 年老代大小 + 元空间大小。元空间通常固定大小为 64m，因此增大年轻代后，将会减少年老代大小。此值对系统性能影响较大，Sun 官方推荐配置为整个堆的 3/8。
9.-Xss128k：设置每一个线程的栈大小。JDK5.0 之后每一个线程堆栈大小为 1M，之前每一个线程堆栈大小为 256K。在相同物理内存下，减少这个值能生成更多的线程。可是操做系统对一个进程内的线程数仍是有限制的在 3000~5000 间。
10.-XX:SurvivorRatio=4：设置年轻代中 Eden 区与 Survivor 区的大小比值。
11.-XX:MaxMetaspaceSize=16m：设置元空间大小为 16m。
12.-XX:MaxTenuringThreshold=0：设置年轻代最大年龄。若是设置为 0 的话，则年轻代对象不通过 Survivor 区，直接进入年老代。对于年老代比较多的应用，能够提升效率。若是将此值设置为一个较大值，则年轻代对象会在 Survivor 区进行屡次复制，这样能够增长对象再年轻代的存活时间，增长在年轻代即被回收的几率。
13.-XX:+DisableExplicitGC：这个将会忽略手动调用 GC 的代码使得 System.gc() 的调用就会变成一个空调用，彻底不会触发任何 GC
-Xmx5120m –Xms5120m -Xmn2g -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxMetaspaceSize=16m -XX:MaxTenuringThreshold=0
2.垃圾回收器配置：
1.Serial 收集器：
-XX:MaxTenuringThreshold 默认值是 15，新生代对象晋升为老年代对象须要通过 15 次 GC。
2.ParNew 收集器：
-XX:MaxTenuringThreshold 默认值是 15，新生代对象晋升为老年代对象须要通过 15 次 GC。
-XX:UseAdaptiveSizePolicy JVM 根据运行参数，动态调整堆空间大小及晋升年龄值。
3.Parallel Scavenge/Parallel Old 收集器：
-XX:ParallelGCThreads 设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。
-XX:UseAdaptiveSizePolicy JVM根据运行参数，动态调整堆空间大小及晋升年龄值
-XX:MaxTenuringThreshold 默认值是15，新生代对象晋升为老年代对象须要通过15次GC
-XX:GCTimeRatio 设置垃圾回收时间占程序运行时间的百分比（默认99），公式为1/(1+n)
-XX:MaxGCPauseMillis 设置并行收集最大暂停时间。
4.CMS 收集器：
-XX:ParallelCMSThreads 垃圾收集器线程数
-XX:CMSFullGCsBeforeCompaction CMS 采用标记-清理算法，会产生内存碎片，配置执行多少次 FullGC 后对内存进行整理。
-XX:UseCMSCompactAtFullCollection 配置 FullGC 后是否当即整理内存碎片。
-XX:CMSInitiatingOccupancyFraction 配置老年代内存使用率达到多少后进行内存回收（ JDK6 及以上版本默认值 92%）。
-XX:CMSInitiatingOccupancyOnly 默认 false，不容许 HostSpot 根据成本自行进行决定什么时候进行垃圾回收。
-XX:CMSClassUnloadingEnabled 配置方法区使用 CMS 进行垃圾回收。
-XX:+CMSIncrementalMode 设置为增量模式，适用于单 CPU 状况。
-XX:+PrintGCApplicationStoppedTime 打印程序 Stop-the-World 的暂停时间。
5.G1 收集器：
-XX:G1ReservePercent 默认值 10%，预留的空闲空间的百分比。
-XX:G1HeapRegionSize 配置 Region 块的大小，范围 1MB 到 32MB，设置后会根据最小堆 Java 堆内存划分出 2048 个 Region 块。
3.垃圾收集统计配置：
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps：可与上面参数一块儿使用
-XX:+PrintGCApplicationConcurrentTime：打印每次垃圾回收前，程序未中断的执行时间，可与上面参数一块儿使用
-XX:+PrintGCApplicationStoppedTime：打印垃圾回收期间程序暂停的时间，可与上面参数一块儿使用
-XX:PrintHeapAtGC：打印 GC 先后的详细堆栈信息
-Xloggc:filename：与上面几个配合使用，把日志信息记录到文件来分析
经过设定 -XX:+UseG1GC 在整个 Java 堆使用 G1 进行垃圾回收
经过 -XX:+UseConcMarkSweepGC 设定新生代使用 ParNew（并发复制）收集器，老年代使用 CMS Concurrent Mark-Sweep（并发标记清除）收集器执行内存回收
经过 -XX:+UseParallelOldGC 手动指定新生代使用 Parallel Scavenge（并行复制）收集器，老年代使用 Parallel Old（并行标记-压缩）收集器执行内存回收
经过 -XX:+UseSerialGC 手动指定新生代使用 Serial Coping（串行复制）收集器，老年代使用 Serial Old （串行标记-清理-压缩）收集器执行内存回收
经过 -XX:+UseParNewGC 手动指定新生代使用 ParNew（并发复制）收集器，老年代使用 Serial Old （串行标记-清理-压缩）收集器执行内存回收
经过 -XX:+UseParallelGC 手动指定新生代使用 Parallel Scavenge（并行复制）收集器，老年代使用 Serial Old （串行标记-清理-压缩）收集器执行内存回收
4.GC日志分析
/** * Created by cong on 2018/8/1. * * 堆溢出 * 经过run configurations配置下列参数 * VM Args：-Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails * -XX:SurvivorRatio=8 -XX:+UseSerialGC * -XX:+HeapDumpOnOutOfMemoryError * 参数-XX：+HeapDumpOnOutOfMemoryError可让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便过后进行分析,文件在项目中lib目录的外层目录下 */ public class HeapOutOfMemory { static class OutOfMemoryObject { } public static void main(String[] args) { List<OutOfMemoryObject> list = new ArrayList<OutOfMemoryObject>(); while (true) { list.add(new OutOfMemoryObject()); } } }
在IDE上面配置虚拟机参数，以下：
而后点击 run，若是报错，那就是虚拟机参数里带了中文标点或者参数名字错了，使用 Serial Coping（串行复制）/Serial Old （串行标记-清理-压缩）组合打印的日志，日志跟下面的使用
-XX:+UseParallelOldGC 打印的日志相似，参考下面 Parallel 的日志分析。
-XX:+UseParNewGC 使用 ParNew（并发复制）/Serial Old （串行标记-清理-压缩），日志跟下面的使用 -XX:+UseParallelOldGC 打印的日志相似，参考下面 Parallel 的日志分析。
-XX:+UseParallelOldGC 使用 Parallel Scavenge（并行复制）/ Parallel Old（并行标记-压缩） 。日志分析以下:
[GC [PSYoungGen: 7469K->1016K(9216K)] 7469K->5241K(19456K), 0.0110178 secs] [Times: user=0.05 sys=0.02, real=0.01 secs] /* * [PSYoungGen: 7469K->1016K(9216K)] PSYoungGen在新生代发生Minor * GC，回收前内存占用7469K，回收后内存占用1016K，新生代的总内存大小 7469K->5241K(19456K) * Java整个堆空间的内存占用变化，回收前7469K，回收 后5241K，整个堆19456K 0.0110178 secs，整个Minor * GC耗时多少秒，[Times: user=0.05 sys=0.02, real=0.01 secs] user程序耗时，sys系统耗时，real实际耗时 * 多少秒 */ [GC-- [PSYoungGen: 9208K->9208K(9216K)] 13433K->19440K(19456K), 0.0166318 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] [Full GC [PSYoungGen: 9208K->0K(9216K)] [ParOldGen: 10232K->10207K(10240K)] 19440K->10207K(19456K) [PSPermGen: 2632K->2631K(21504K)], 0.1698064 secs] [Times: user=0.34 sys=0.00, real=0.17 secs] [Full GC [PSYoungGen: 7735K->7728K(9216K)] [ParOldGen: 10207K->8097K(10240K)] 17942K->15826K(19456K) [PSPermGen: 2631K->2631K(21504K)], 0.1632131 secs] [Times: user=0.42 sys=0.00, real=0.15 secs] /* * Full GC代码整个堆的GC，PSYoungGen新生代内存使用变化，ParOldGen老年代内存使用变化，PSPermGen永久代内存使用变化，0. * 1632131 secs本次Full GC消耗多少秒，Times: user=0.42 sys=0.00, real=0.15 secs 本次Full * GC各类时间消耗，全部参数含义跟上面同样。 */ [Full GC [PSYoungGen: 7728K->7728K(9216K)] [ParOldGen: 8097K->8089K(10240K)] 15826K->15818K(19456K) [PSPermGen: 2631K->2631K(21504K)], 0.0952587 secs] [Times: user=0.33 sys=0.02, real=0.10 secs] java.lang.OutOfMemoryError: Java heap space // 生成的堆快照文件java_pid26276.hprof，在lib目录下 Dumping heap to java_pid26276.hprof ...
-XX:+UseConcMarkSweepGC 使用ParNew（并发复制）/ CMS Concurrent Mark-Sweep（并发标记清除）,日志以下：
[GC[ParNew: 7469K->1024K(9216K), 0.0339335 secs] 7469K->7079K(19456K), 0.0339810 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] // 新生代使用ParNew作垃圾回收，参数含义跟上面分析的同样 Total time for which application threads were stopped: 0.0341067 seconds /* 程序暂停时间0.0341067秒，-XX:+PrintGCApplicationStoppedTime打印程序Stop-the-World的暂停时间 */ [GC[ParNew: 9216K->9216K(9216K), 0.0000205 secs][CMS: 6055K->8941K(10240K), 0.0319501 secs] 15271K->13881K(19456K), [CMS Perm : 2630K->2629K(21248K)], 0.0320168 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] Total time for which application threads were stopped: 0.0321285 seconds [GC [1 CMS-initial-mark: 8941K(10240K)] 13881K(19456K), 0.0035077 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] /*CMS初始标记，老年代内存占用大小8941K，总大小10240K，标记跟根对象集合直接相链接的对象的可达性*/ Total time for which application threads were stopped: 0.0035747 seconds [Full GC[CMS[CMS-concurrent-mark: 0.011/0.011 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] //并发标记，从上次初始标记对象出发，标记垃圾对象和可回收对象 (concurrent mode failure): 8941K->8940K(10240K), 0.0385219 secs] 14326K->13896K(19456K), [CMS Perm : 2632K->2632K(21248K)], 0.0385659 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] /* * 并发标记期间，新生成的对象在老年代没法有足够的内存容纳，产生concurrent mode * failure，老年代改用串行收集器，若是不产生concurrent mode * failure，后面还有CMS-remark，作最终标记，修正标记，会有暂停时间和内存占用和总内存，最后就是CMS-cocurrent-sweep， * 并发清除，会有清除耗时 */ Total time for which application threads were stopped: 0.0387397 seconds
接着咱们将上面的例子进行改造，改造以下：
/** * Created by cong on 2018/8/1. * * 堆溢出 * 经过run configurations配置下列参数 * VM Args：-Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails * -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC * -XX:+HeapDumpOnOutOfMemoryError * 参数-XX：+HeapDumpOnOutOfMemoryError可让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便过后进行分析,文件在项目中lib目录的外层目录下 */ public class HeapOutOfMemory { static class OutOfMemoryObject { public byte[] spaceSize = new byte[1024 * 1024]; // 产生1024*1024个字节，也就是1024*1KB的内存 ，大小1MB } public static void creatHeap(int num) throws Exception { ArrayList<OutOfMemoryObject> list = new ArrayList<OutOfMemoryObject>(); for (int i = 0; i < num; i++) { list.add(new OutOfMemoryObject()); } System.gc(); } public static void main(String[] args) throws Exception { while (true) { creatHeap(99); } } }
运行结果的，日志分析以下：
[GC[ParNew: 8111K->8111K(9216K), 0.0000122 secs][CMS: 7176K->9216K(10240K), 0.0104259 secs] 15287K->14839K(19456K), [CMS Perm : 2632K->2632K(21248K)], 0.0104885 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] Total time for which application threads were stopped: 0.0106245 seconds [GC [1 CMS-initial-mark: 9216K(10240K)] 15863K(19456K), 0.0004189 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] Total time for which application threads were stopped: 0.0006342 seconds [Full GC[CMS[CMS-concurrent-mark: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] (concurrent mode failure): 9216K->9216K(10240K), 0.0043732 secs] 16947K->16887K(19456K), [CMS Perm : 2632K->2632K(21248K)], 0.0044245 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] java.lang.OutOfMemoryError: Java heap space Dumping heap to java_pid1264.hprof ... Total time for which application threads were stopped: 0.0171680 seconds Heap dump file created [17857505 bytes in 0.018 secs] [GC [1 CMS-initial-mark: 9216K(10240K)] 16876K(19456K), 0.0005822 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] Total time for which application threads were stopped: 0.0014073 seconds [CMS-concurrent-mark: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [CMS-concurrent-preclean: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [CMS-concurrent-abortable-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC[YG occupancy: 7863 K (9216 K)][Rescan (parallel) , 0.0002252 secs][weak refs processing, 0.0000048 secs][scrub string table, 0.0001071 secs] [1 CMS-remark: 9216K(10240K)] 17079K(19456K), 0.0003718 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] /* * CMS-remark，作最终标记，修正标记，老年代已用内存9216K，总内存10240K，耗时 0.0003718 */ Total time for which application threads were stopped: 0.0005235 seconds [CMS-concurrent-mark: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] /* * CMS-cocurrent-sweep，并发清除耗时0.002秒 */
经过设定 -XX:+UseG1GC 在整个 Java 堆使用 G1 进行垃圾回收，日志分析以下：
[GC pause (young) (initial-mark), 0.0028719 secs] [Parallel Time: 2.2 ms, GC Workers: 4] [GC Worker Start (ms): Min: 168.7, Avg: 168.8, Max: 168.9, Diff: 0.2] [Ext Root Scanning (ms): Min: 0.9, Avg: 1.1, Max: 1.5, Diff: 0.6, Sum: 4.6] [Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] [Processed Buffers: Min: 0, Avg: 2.0, Max: 8, Diff: 8, Sum: 8] [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] [Object Copy (ms): Min: 0.1, Avg: 0.3, Max: 0.5, Diff: 0.4, Sum: 1.3] [Termination (ms): Min: 0.0, Avg: 0.4, Max: 0.5, Diff: 0.5, Sum: 1.4] [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1] [GC Worker Total (ms): Min: 1.6, Avg: 1.8, Max: 2.0, Diff: 0.4, Sum: 7.3] [GC Worker End (ms): Min: 170.3, Avg: 170.6, Max: 170.8, Diff: 0.5] [Code Root Fixup: 0.0 ms] [Clear CT: 0.1 ms] [Other: 0.6 ms] [Choose CSet: 0.0 ms] [Ref Proc: 0.5 ms] [Ref Enq: 0.0 ms] [Free CSet: 0.0 ms] [Eden: 1024.0K(10.0M)->0.0B(9216.0K) Survivors: 0.0B->1024.0K Heap: 4857.6K(20.0M)->4720.2K(20.0M)] [Times: user=0.00 sys=0.00, real=0.00 secs] Total time for which application threads were stopped: 0.0036639 seconds // 初始标记以及暂停时间0.0036639 seconds [GC concurrent-root-region-scan-start] [GC concurrent-root-region-scan-end, 0.0005495 secs] // 扫描根region,耗时0.0005495 secs [GC concurrent-mark-start] [GC concurrent-mark-end, 0.0004523 secs] // 并发标记，耗时0.0004523 secs [GC remark [GC ref-proc, 0.0000279 secs], 0.0006380 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] Total time for which application threads were stopped: 0.0008879 seconds [GC cleanup 6809K->6809K(20M), 0.0006380 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] // 清除阶段 Total time for which application threads were stopped: 0.0006810 seconds [GC pause (young) (to-space exhausted), 0.0044659 secs] [Parallel Time: 4.0 ms, GC Workers: 4] [GC Worker Start (ms): Min: 176.6, Avg: 176.6, Max: 176.6, Diff: 0.0] //Parallel Time 并行处理的部分占用时间，Worker Start – 工做线程启动的时刻 [Ext Root Scanning (ms): Min: 0.3, Avg: 0.3, Max: 0.3, Diff: 0.1, Sum: 1.1] //External root scanning 扫描外部根锁使用的时间 [Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] //Update Remembered Set 开始前更新缓存列表，后续并发线程能够正确处理 [Processed Buffers: Min: 0, Avg: 0.5, Max: 2, Diff: 2, Sum: 2] [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] //Scanning Remembered Sets 查询指向收集区域的指针. [Object Copy (ms): Min: 2.6, Avg: 3.4, Max: 3.7, Diff: 1.1, Sum: 13.6] //Object copy 每一个独立线程复制和消亡对象锁花费的时间 [Termination (ms): Min: 0.0, Avg: 0.3, Max: 1.1, Diff: 1.1, Sum: 1.2] //Termination time 当一个工做线程结束了它对特定对象的复制和扫描 [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] [GC Worker Total (ms): Min: 4.0, Avg: 4.0, Max: 4.0, Diff: 0.0, Sum: 15.9] //GC Worker Total– 全部GC线程所使用的时间 [GC Worker End (ms): Min: 180.6, Avg: 180.6, Max: 180.6, Diff: 0.0] [Code Root Fixup: 0.0 ms] [Clear CT: 0.0 ms] [Other: 0.4 ms] [Choose CSet: 0.0 ms] [Ref Proc: 0.0 ms] [Ref Enq: 0.0 ms] [Free CSet: 0.0 ms] //释放那些已经被收集过的区域，remembered sets所花费的时间 [Eden: 1024.0K(9216.0K)->0.0B(10.0M) Survivors: 1024.0K->0.0B Heap: 9901.8K(20.0M)->9901.8K(20.0M)] [Times: user=0.00 sys=0.00, real=0.00 secs] Total time for which application threads were stopped: 0.0046272 seconds [Full GC 9901K->9719K(20M), 0.0030929 secs] [Eden: 0.0B(10.0M)->0.0B(10.0M) Survivors: 0.0B->0.0B Heap: 9901.8K(20.0M)->9719.5K(20.0M)] [Times: user=0.00 sys=0.00, real=0.00 secs] [Full GC 9719K->9708K(20M), 0.0028649 secs] [Eden: 0.0B(10.0M)->0.0B(10.0M) Survivors: 0.0B->0.0B Heap: 9719.5K(20.0M)->9708.5K(20.0M)] [Times: user=0.00 sys=0.00, real=0.00 secs] Total time for which application threads were stopped: 0.0060723 seconds java.lang.OutOfMemoryError: Java heap space Dumping heap to java_pid11772.hprof ... Total time for which application threads were stopped: 0.0118791 seconds Heap dump file created [10622284 bytes in 0.012 secs] Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at com.jvm.outofmemory.HeapOutOfMemory$OutOfMemoryObject.<init>(HeapOutOfMemory.java:14) at com.jvm.outofmemory.HeapOutOfMemory.creatHeap(HeapOutOfMemory.java:21) at com.jvm.outofmemory.HeapOutOfMemory.main(HeapOutOfMemory.java:28) Heap garbage-first heap total 20480K, used 9708K [0x00000000f9a00000, 0x00000000fae00000, 0x00000000fae00000) region size 1024K, 1 young (1024K), 0 survivors (0K) compacting perm gen total 20480K, used 2663K //region 大小1M，一个年轻代region，没有幸存代region [0x00000000fae00000, 0x00000000fc200000, 0x0000000100000000) the space 20480K, 13% used [0x00000000fae00000, 0x00000000fb099cd0, 0x00000000fb099e00, 0x00000000fc200000) No shared spaces configured.
5.异常信息：
1.java.lang.OutOfMemoryError: PermGen space：永久代被占满，没法为 class 字节码文件分配空间，如今反射，动态代理使用愈来愈多，字节码插桩技术能够在类加载的先后插入自定义的内容，这些都会增大永久代的占用。
2.java.lang.OutOfMemoryError: Java heap space：内存泄漏
3.java.lang.StackOverflowError：栈空间溢出，一般是栈帧深度过深，如递归调用没有出口，形成死循环。
4.Fatal: Stack size too small：线程栈爆满，一般是方法体代码过多形成，能够经过拆分方法，让方法职责单一避免溢出，也能够经过 -Xss 增大线程栈空间。
6.Java引用类型：
1.强引用：强引用指向的对象在任什么时候候都不会被系统回收。即便当内存不足时，VM宁愿抛出内存不足的异常，也不会去回收这些对象。
使用场景：咱们日常大部分使用的场景都是使用了强引用，好比new建立对象，反射得到一个对象等。以下：
Object obj = new Object();
2.软引用：一个持有软引用的对象，不会被 JVM 很快地回收，JVM 会根据当前堆的使用状况来判断什么时候回收。（一般用于缓存），若是内存空间不足时，就会回收这些对象的内存。
软引用还能够和一个引用队列进行关联，若是这个软引用的对象被垃圾回收，那么VM就会将这个软引用加入到关联的队列中去。
使用场景： 这种可用于那种有可能会在建立后使用的对象，不过为了内存消耗会选择使用软引用，好比缓存。以下所示：
String cache = "{a=1,b=2,c=3,d=4}"; SoftReference<String> stringSoftReference = new SoftReference<String>(cache); System.out.println(cache);
3.弱引用：在系统 GC 时，只要发现弱引用，无论系统队空间是否足够，都会将对象进行回收。弱引用和软引用的区别在于，只具备弱引用的对象拥有更短暂的生命周期，在垃圾回收器线程扫描它管辖的内存区域的过程当中，一旦发现对象只具备弱引用，无论当前内存空间是否足够，都会回收他的内存。 它比软引用的生命周期更短，和软引用类似，它一样能够和引用队列关联，若是被垃圾回收了，就会加入到这个关联队列中。
使用场景： 弱引用用于生命周期更短的，对内存更敏感的场景中，好比占用内存很大的Map，java api中就提供了WeakHashMap使用，就会是的大Map被及时清理掉。以下：
WeakHashMap<String,Bean> weakHashMap = new WeakHashMap<>(); weakHashMap.put("a",new Bean(1)); weakHashMap.put("b",new Bean(2)); weakHashMap.put("c",new Bean(3)); System.out.println(weakHashMap);
4.虚引用：和没有引用几乎同样。虚引用”形同虚设，与其余几种引用都不一样，虚引用并不会决定对象的生命周期，若是一个对象仅持有虚引用的话，那么它就和没有任何的引用同样，在任什么时候候均可能被垃圾回收器回收。 虚引用必须和引用队列联合使用，引用队列的做用和软弱引用同样。
使用场景： 我以为他的使用场景应该在判断一个对象是否被垃圾回收了。例子以下：
String name = "a"; ReferenceQueue<String> prq = new ReferenceQueue<>(); PhantomReference<String> nameRf = new PhantomReference<>(name, prq); System.out.println(prq.poll());
接下来进行一个例子演示Java的引用类型，以下：
package com; import java.util.ArrayList; import java.util.List; import java.util.Map; import java.util.WeakHashMap; /** * Created by cong on 2018/8/5. */ public class WeakReference { // 弱引用 public static Map map = new WeakHashMap(); // 强引用 public static List list = new ArrayList(); public static void main(String[] args) { for (int i = 0; i < 999; i++) { Integer j = new Integer(i); // j强引用 list.add(j); // 存放在weakHashMap中的key都存在强引用，那么weakHashMap就退化为HashMap，即强引用 map.put(j, new byte[i]); // 当内存足不足时，会报OutOfMemoryError，由于存在j强引用，没有被使用的map存在的垃圾却没法被清理，形成内存泄漏 } // //把for循环替换成 // for(int i=0;i<999;i++){ // Integer k = new Integer(i); // map.put(k,new byte[i]); // //当内存不足时，会被自动回收，weakHashMap 会在内存紧张时，自动释放持有弱引用的数据 // } } }
二.JVM 问题排查
1.CPU 使用率太高时：
- 经过 top 命令查看服务器的负载状况
- 经过
top+H查看线程的使用状况 - 经过
jstat -gcutil pid查看具体线程的 GC 先后内存变化（pid的地方用进程号代替） ps -mp pid -o THREAD,tid,time查看线程列表printf "%x\n" tid将 tid 转换成 16 进制格式jstack pid |grep tid -A 60打印线程（转换后 16 进制格式的数字）tid 的堆栈信息- 一般计算密集型应用产生死锁或者死循环或超时重试致使的线程堆积都会占用 CPU 大量资源，CPU 使用率可能达到 200%
2.线上频繁 Full GC：
1.经过 top+H 查看线程的使用状况
2.jmap -histo:live pid（进程号） 这个会当即触发 Full GC
3.线上开启了 -XX:+HeapDumpBeforeFullGC 也就是 FullGC 前保存内存快照，JVM 在执行 dump 操做的时是会发生 stop the word，此时全部的用户线程都会暂停运行。为了对外能正常提供服务，可用分布式部署，匹配负载均衡
4.经过 MAT（Memory Analyzer Tool）分析内存快照，把 “Keep unreachable objects” 勾上，不然 MAT 会把堆中不可达的对象去除掉，反而不利于分析， 经过 -XX：+HeapDumpOnOutOfMemoryError 可让虚拟机在出现内存溢出异常时 Dump 出当前的内存堆转储快照，而后看到 GC 日志 Dumping heap to java_pid11772.hprof ...，咱们能够在工程目录里打开 pid11772.hprof 日志文件（在 Eclipse 应用市场下载 Memory Analyzer Tool 插件并安装，就能够直接打开）
5.查看 Dominator Tree 选项，内存中全部对象都按照内存消耗排名从高到低进行排序
Class Name 是 Java 类的全限定名 Shallow Heap 是对象自己消耗内存大小。
Retained Heap 是对象自己和它所引用的对象的内存大小总和。
Percenttage 是对象消耗占整个堆快照的比率。
6.查看是否使用了大对象，或者长期持有对象的引用，或者大量堆积了全局的本地缓存
电商平台，在作活动促销时，瞬间有大量的客户登陆，可是登陆页面假死，形成登陆失败，在服务器的 log 日志发现大量的超时信息，报线程耗尽，经过 jstack pid 打印进程中线程堆栈信息发现有上百个 thread 不断的重试发送请求，基本定位是大量超时请求重试致使服务器高负荷运行而假死。
咱们把服务端提供者登陆接口的线程并发数从 10 调成 15，并把消费者重试次数改成 0，请求失败后直接返回，让用户的客户端 Http 进行重试，同时在登陆时关闭 Druid 的 SQL 监控功能，避免增长额外资源消耗，最后从新上线，问题修复。
JVM 生产监控的指标有哪些？
关于 GC 的监控，我认为最重要的三点为：
- 各个区的容量。
- Full GC、Young GC 发生的次数。
- 当前系统的内存比、CPU 使用率。
咱们以 java/bin/jstat 为例看看相关的参数细节有哪些。
| 数据列 | 描述 | 支持的jstat 选项 |
|---|---|---|
| S0C | Survivor0的当前容量 | -gc -gccapacity -gcnew -gcnewcapacity |
| S1C | S1的当前容量 | -gc -gccapacity -gcnew -gcnewcapacity |
| S0U | S0的使用量 | -gc-gcnew |
| S1U | S1的使用量 | -gc-gcnew |
| EC | Eden区的当前容量 | -gc -gccapacity -gcnew -gcnewcapacity |
| EU | Eden区的使用量 | -gc -gcnew |
| OC | old区的当前容量 | -gc -gccapacity -gcnew -gcnewcapacity |
| OU | old区的使用量 | -gc-gcnew |
| PC | 方法区的当前容量 | -gc-gccapacity -gcold -gcoldcapacity -gcpermcapacity |
| PU | 方法区的使用量 | -gc -gcold |
| YGC | Young GC次数 | -gc -gccapacity -gcnew -gcnewcapacity -gcold -gcoldcapacity -gcpermcapacity -gcutil -gccause |
| YGCT | Young GC累积耗时 | -gc -gcnew -gcutil -gccause |
| FGC | Full GC次数 | -gc -gccapacity -gcnew -gcnewcapacity -gcold -gcoldcapacity -gcpermcapacity -gcutil -gccause |
| FGCT | Full GC累积耗时 | -gc-gcold -gcoldcapacity -gcpermcapacity -gcutil -gccause |
| GCT | GC总的累积耗时 | -gc -gcold -gcoldcapacity -gccapacity -gcpermcapacity -gcutil -gccause |
| NGCMN | 新生代最小容量 | -gccapacity -gcnewcapacity |
| NGCMX | 新生代最大容量 | -gccapacity -gcnewcapacity |
| NGC | 新生代当前容量 | -gccapacity -gcnewcapacity |
| OGCMN | 老年代最小容量 | -gccapacity -gcoldcapacity |
| OGCMX | 老年代最大容量 | -gccapacity -gcoldcapacity |
| OGC | 老年代当前容量 | -gccapacity -gcoldcapacity |
| PGCMN | 方法区最小容量 | -gccapacity -gcpermcapacity |
| PGCMX | 方法区最大容量 | -gccapacity -gcpermcapacity |
| PGC | 方法区当前容量 | -gccapacity -gcpermcapacity |
| PC | 方法区的当前容量 | -gccapacity -gcpermcapacity |
| PU | 方法区使用量 | -gccapacity -gcold |
| LGCC | 上一次GC发生的缘由 | -gccause |
| GCC | 当前GC发生的缘由 | -gccause |
| TT | 存活阀值，若是对象在新生代移动次数超过此阀值，则会被移到老年代 | -gcnew |
| MTT | 最大存活阀值，若是对象在新生代移动次数超过此阀值，则会被移到老年代 | -gcnew |
| DSS | survivor区的理想容量 | -gcnew |
轻松应对 JVM 的面试和实际工做。
针对面试，建议读者保持两点：
- 思路清晰，说的是通的。建议读者能够根据做者整理的内容弄个简单的思路导图。
- 面要全，有一到两个点要细。概况起来了就三点，以下。
- 不一样视角的内存模型、
- GC 对应的4种算法。
- GC 对应的5种收集器。
针对于工做，但愿你们了解如下几点：
- 必定要知道 JDK 版本，JVM 默认参数有哪些？
- 我能够设置哪些？哪些是必须设置的？
- 能够直接参看不少容器，如 Tomcat、Jetty、Docker 的默认 JVM 参数。
- 1. 性能优化之笔记
- 2. JVM性能优化读后笔记
- 3. Android高级特性笔记
- 4. 性能优化之jvm
- 5. MySQL高级--性能优化
- 6. mysql高级性能优化
- 7. 性能优化（JVM优化）
- 8. Mysql高级性能优化之Explain（八）
- 9. 性能优化——记高性能MySQL
- 10. JVM性能优化
- 更多相关文章...
- • XML DOM 高级 - XML 教程
- • MySQL 5.7的新特性（新功能） - MySQL教程
- • JDK13 GA发布：5大特性解读
- • Tomcat学习笔记（史上最全tomcat学习笔记）
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 性能优化之笔记
- 2. JVM性能优化读后笔记
- 3. Android高级特性笔记
- 4. 性能优化之jvm
- 5. MySQL高级--性能优化
- 6. mysql高级性能优化
- 7. 性能优化（JVM优化）
- 8. Mysql高级性能优化之Explain（八）
- 9. 性能优化——记高性能MySQL
- 10. JVM性能优化