解决JVM运行中的问题 一个案例理解常用工具 测试代码： /** * 从数据库中读取信用数据，套用模型，并把结果进行记录和传输 */ public class T15_FullGC_Problem01 { private static class CardInfo { BigDecimal price = new BigDecimal(0.0); String name = "张三"; int age = 5; Date birthdate = new Date(); public void m() {} } private static ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(50, new ThreadPoolExecutor.DiscardOldestPolicy()); public static void main(String[] args) throws Exception { executor.setMaximumPoolSize(50); for (;;){ modelFit(); Thread.sleep(100); } } private static void modelFit(){ List<CardInfo> taskList = getAllCardInfo(); taskList.forEach(info -> { // do something executor.scheduleWithFixedDelay(() -> { //do sth with info info.m(); }, 2, 3, TimeUnit.SECONDS); }); } private static List<CardInfo> getAllCardInfo(){ List<CardInfo> taskList = new ArrayList<>(); for (int i = 0; i < 100; i++) { CardInfo ci = new CardInfo(); taskList.add(ci); } return taskList; } } java -Xms200M -Xmx200M -XX:+PrintGC com.mashibing.jvm.gc.T15_FullGC_Problem01 一般是运维团队首先受到报警信息（CPU Memory） top命令观察到问题：内存不断增长 CPU占用率居高不下 top -Hp +pid观察进程中的线程，哪个线程CPU和内存占比高 jps定位具体java进程 jstack 定位线程状况，重点关注：WAITING BLOCKED jstack +PID
eg.
waiting on condition [0xe7f5a000] (a java.lang.Object) 假如有一个进程中100个线程，很多线程都在waiting on <xx> ， 一定要找到是哪个线程持有这把锁
怎么找？搜索jstack dump的信息，找<xx> ，看哪个线程持有这把锁RUNNABLE
作业：1：写一个死锁程序，用jstack观察 2 ：写一个程序，一个线程持有锁不释放，其他线程等待 为什么阿里规范里规定，线程的名称（尤其是线程池）都要写有意义的名称 怎么样自定义线程池里的线程名称？（自定义ThreadFactory） jinfo pid 查询虚拟机信息
jstat -gc 动态观察gc情况 / 阅读GC日志发现频繁GC / arthas观察 / jconsole/jvisualVM/ Jprofiler（最好用） jstat -gc 4655 500 :
每个500个毫秒打印GC的情况 如果面试官问你是怎么定位OOM问题的？如果你回答用图形界面（错误）
1：已经上线的系统不用图形界面用什么？（cmdline arthas） 2：图形界面到底用在什么地方？测试！测试的时候进行监控！（压测观察） jmap - histo 4655 | head -20，查找有多少对象产生
jmap -dump:format=b,file=xxx pid 1361：
-XX:HeapDumpPath=/x/x 配置jvm启动参数也可以dump 堆文件
线上系统，内存特别大，jmap -demp执行期间会对进程产生很大影响，甚至卡顿（电商不适合） 1：设定了参数HeapDump，OOM的时候会自动产生堆转储文件 2：很多服务器备份（高可用），停掉这台服务器对其他服务器不影响 3：在线定位(一般小点儿公司用不到) java -Xms20M -Xmx20M -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError T15_FullGC_Problem01 使用MAT / jhat /jvisualvm 进行dump文件分析 https://www.cnblogs.com/baihuitestsoftware/articles/6406271.html jhat -J-mx512M xxx.dump http://192.168.17.11:7000 拉到最后：找到对应链接 可以使用OQL查找特定问题对象 找到代码的问题 问题分析流程: 慢,CPU飙高->top->Jps->Jstack->Jmap jconsole远程连接 程序启动加入参数： java -Djava.rmi.server.hostname=192.168.65.10 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=11111 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -XX:+PrintGC -Xms200M -Xmx200M T15_FullGC_Problem01 如果遭遇 Local host name unknown：XXX的错误，修改/etc/hosts文件，把XXX加入进去 192.168.65.10 basic localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 关闭linux防火墙（实战中应该打开对应端口） service iptables stop chkconfig iptables off #永久关闭 windows上打开 jconsole远程连接 192.168.17.11:11111
jvisualvm远程连接
https://www.cnblogs.com/liugh/p/7620336.html （简单做法）
arthas在线排查工具 § 启动arthas java -jar arthas-boot.jar § 绑定java进程 § dashboard命令观察系统整体情况 § help 查看帮助 § help xx 查看具体命令帮助 § https://www.jianshu.com/p/507f7e0cc3a3
为什么需要在线排查？
在生产上我们经常会碰到一些不好排查的问题，例如线程安全问题，用最简单的threaddump或者 heapdump不好查到问题原因。为了排查这些问题，有时我们会临时加一些日志，比如在一些关键的函数里打印出入参，然后重新打包发布，如果打了日志还是没找到问题，继续加日志，重新打包发布。对于上线流程复杂而且审核比较严的公司，从改代码到上线需要层层的流转，会大大影响问题排查的进度。 jvm观察jvm信息 thread定位线程问题 thread + ID
dashboard 观察系统情况
heapdump + jhat分析 完成之后ip+7000端口访问
jad反编译
动态代理生成类的问题定位
第三方的类（观察代码）
版本问题（确定自己最新提交的版本是不是被使用）
redefine 热替换
目前有些限制条件：只能改方法实现（方法已经运行完成），不能改方法名， 不能改属性 m() -> mm() 直接线上修改源文件方法内容,完成后重新编译,最后redefine重新替换
sc - search class
watch - watch method 没有包含的功能：jmap 案例汇总 OOM产生的原因多种多样，有些程序未必产生OOM，不断FGC(CPU飙高，但内存回收特别少) （上面案例） 1. 硬件升级系统反而卡顿的问题（见上） 2. 线程池不当运用产生OOM问题（见上） 不断的往List里加对象（实在太LOW） 3. smile jira问题 实际系统不断重启 解决问题 加内存 + 更换垃圾回收器 G1 真正问题在哪儿？不知道 4. tomcat http-header-size过大问题（Hector） 5. lambda表达式导致方法区溢出问题(MethodArea / Perm Metaspace) LambdaGC.java -XX:MaxMetaspaceSize=9M -XX:+PrintGCDetails 6. 直接内存溢出问题（少见） 《深入理解Java虚拟机》P59，使用Unsafe分配直接内存，或者使用NIO的问题 7. 栈溢出问题 -Xss设定太小 8. 比较一下这两段程序的异同，分析哪一个是更优的写法： Object o = null; for(int i=0; i<100; i++) { o = new Object(); //业务处理 } for(int i=0; i<100; i++) { Object o = new Object(); } 9. 重写finalize引发频繁GC 小米云，HBase同步系统，系统通过nginx访问超时报警，最后排查，C++程序员重写finalize引发频繁GC问题 为什么C++程序员会重写finalize？（new 析构函数 delete） finalize耗时比较长（200ms） 10. 如果有一个系统，内存一直消耗不超过10%，但是观察GC日志，发现FGC总是频繁产生，会是什么引起的？ System.gc() (这个比较Low) 11. Distuptor有个可以设置链的长度，如果过大，然后对象大，消费完不主动释放，会溢出 (来自 死物风情) 12. 用jvm都会溢出，mycat用崩过，1.6.5某个临时版本解析sql子查询算法有问题，9个exists的联合sql就导致生成几百万的对象（来自 死物风情） 13. new 大量线程，会产生 native thread OOM，（low）应该用线程池， 解决方案：减少堆空间（太TMlow了）,预留更多内存产生native thread JVM内存占物理内存比例 50% - 80% G1详解 特点: 并发收集 压缩空闲空间不会延长GC的暂停时间; 更易预测的GC暂停时间; 适用不需要实现很高的吞吐量的场景 分区: ○ 每个分区都可能是年轻代也可能是老年代，但是在同一时刻只能属于某个代。 ○ 年轻代、幸存区、老年代这些概念还存在，成为逻辑上的概念，这样方便复用之前分代框架的逻辑。在物理上不需要连续，则带来了额外的好处一有 的分区内垃圾对象特别多，有的分区内垃圾对象很少，G1会优先回收垃圾对象特别多的分区，这样可以花费较少的时间来回收这些分区的垃圾，这也就是G1名字的由来，即首先收集垃圾最多的分区。 ○ 新生代其实并不是适用于这种算法的，依然是在新生代满了的时候，对整个新生代进行回收一整个新生代中的对象，要么被回收、要么晋升，至于新生代也采取分区机制的原因，则是因为这样跟老年代的策略统一， 方便调整代的大小. ○ G1还是一种带 压缩的收集器，在回收老年代的分区时， 是将存活的对象从一个分区拷贝到另一个可用分区，这个拷贝的过程就实现了局部的压缩。每个分区的大小从1M到，32M不等，但是都是2的冥次方。 ○ G1的内存区域不是固定的E或者O,肯在这个阶段是E,在另一个阶段又是O Card Table 由于做YGC时，需要扫描整个OLD区，效率非常低，所以JVM设计了CardTable， 如果一个OLD区CardTable中有对象指向Y区，就将它设为Dirty，下次扫描时， 只需要扫描Dirty Card 在结构上，Card Table用BitMap来实现
CSet(Collection Set)
一组可被回收的分区的集合。 在CSet中存活的数据会在GC过程中被移动到另一个可用分区， CSet中的分区可以来自Eden空间、survivor空间、 或者老年代。 CSet会占用不到整个堆空间的1%大小。 RSet (RememberedSet) 记录了其他Region中的对象到本Region的引用 RSet的价值在于 使得垃圾收集器不需要扫描整个堆找到谁引用了当前分区中的对象，只需要扫描RSet即可。 每个region有多大 取值范围: 1 2 4 8 16 32 humongous object 超过单个region的50% 跨越多个region
G1 GC何时触发
YGC Eden空间不足 多线程并行执行 FGC Old空间不足 System.gc() MixedGC(类似CMS) XX:InitiatingHeapOccupacyPercent 默认值45% 当0超过这个值时，启动MixedGC MixedGC的过程 初始标记STW 并发标记 最终标记STW (重新标记) 筛选回收STW (并行) 三色标记算法 并发阶段标记算法 (三色标记,颜色指针) 并发标记算法难点:在标记过程中,对象引用关系正在发生改变(浮动垃圾) 三色标记法 定义: 白色:未被标记的对象 灰色:自身被标记，成员变量未被标记 黑色:自身和成员变量均已标记完成 漏标 在remark过程中，黑色指向了白色，如果不对黑色重新扫描，则会漏标 会把白色D对象当做没有新引用指向从而回收掉并发标记过程中，Mutator删除 了 所有从灰色到白色的引用，会产生漏标此时白色对象应该被回收 漏标案例: A(黑):自己已经标记，fields 都标记完成 B(灰):自己标记完成，还没来得及标记fields C(灰):自己标记完成，还没来得及标记fields D(白):没有遍历到的节点 产生漏标: 1.标记进行时增加了一个黑到白的引用，如果不重新对黑色进行处理，则会漏标 2.标记进行时删除了灰对象到白对象的引用，那么这个白对象有可能被漏标 解决漏标: 打破以下两个条件之一即可 1. incremental update增量更新，关注引用的增加， 把黑色重新标记为灰色，下次重新扫描属性 2. SATB (snapshot at the beginning)-关注引用的删除 当B->D消失时，要把这个引用推到GC的堆栈，保证D还能被GC描到 CMS用第一种,G1用第二种 为什么G1用SATB? □ 灰色-->白色引用消失时，如果没有黑色指向白色引用会被push到堆栈 □ 下次扫描时拿到这个引用，由于有RSet的存在，不需要扫描整个堆去查找指向白色的引用，效率比较高 □ SATB配合RSet,浑然天成 为什么选择G1 ○ 追求吞吐量 § 100 cpu § 99 app 1 GC § 吞吐量= 99% ○ 追求响应时间 § - XX:MaxGCPauseMillis 200 § 对STW进行控制 ○ 灵活 § 分Region回收 § 优先回收花费时间少、垃圾比例高的Region GC常用参数 • -Xmn -Xms -Xmx -Xss ○ 年轻代 初始堆 最大堆 栈空间 • -XX:+UseTLAB ○ 使用TLAB，默认打开 • -XX:+PrintTLAB ○ 打印TLAB的使用情况 • -XX:TLABSize ○ 设置TLAB大小 • -XX:+DisableExplictGC ○ System.gc()不管用 ，FGC • -XX:+PrintGC • -XX:+PrintGCDetails • -XX:+PrintHeapAtGC • -XX:+PrintGCTimeStamps • -XX:+PrintGCApplicationConcurrentTime (低) ○ 打印应用程序时间 • -XX:+PrintGCApplicationStoppedTime （低） ○ 打印暂停时长 • -XX:+PrintReferenceGC （重要性低） ○ 记录回收了多少种不同引用类型的引用 • -verbose:class ○ 类加载详细过程 • -XX:+PrintVMOptions • -XX:+PrintFlagsFinal -XX:+PrintFlagsInitial ○ 必须会用 • -Xloggc:opt/log/gc.log • -XX:MaxTenuringThreshold ○ 升代年龄，最大值15 • 锁自旋次数 -XX:PreBlockSpin 热点代码检测参数-XX:CompileThreshold 逃逸分析 标量替换 ... ○ 这些不建议设置 Parallel常用参数 • -XX:SurvivorRatio • -XX:PreTenureSizeThreshold ○ 大对象到底多大 • -XX:MaxTenuringThreshold • -XX:+ParallelGCThreads ○ 并行收集器的线程数，同样适用于CMS，一般设为和CPU核数相同 • -XX:+UseAdaptiveSizePolicy ○ 自动选择各区大小比例 CMS常用参数 • -XX:+UseConcMarkSweepGC • -XX:ParallelCMSThreads ○ CMS线程数量 • -XX:CMSInitiatingOccupancyFraction ○ 使用多少比例的老年代后开始CMS收集，默认是68%(近似值)，如果频繁发生SerialOld卡顿，应该调小，（频繁CMS回收） • -XX:+UseCMSCompactAtFullCollection ○ 在FGC时进行压缩 • -XX:CMSFullGCsBeforeCompaction ○ 多少次FGC之后进行压缩 • -XX:+CMSClassUnloadingEnabled • -XX:CMSInitiatingPermOccupancyFraction ○ 达到什么比例时进行Perm回收 • GCTimeRatio ○ 设置GC时间占用程序运行时间的百分比 • -XX:MaxGCPauseMillis ○ 停顿时间，是一个建议时间，GC会尝试用各种手段达到这个时间，比如减小年轻代 G1常用参数 • -XX:+UseG1GC • -XX:MaxGCPauseMillis ○ 建议值，G1会尝试调整Young区的块数来达到这个值 • -XX:GCPauseIntervalMillis ○ GC的间隔时间 • -XX:+G1HeapRegionSize ○ 分区大小，建议逐渐增大该值，1 2 4 8 16 32。 随着size增加，垃圾的存活时间更长，GC间隔更长，但每次GC的时间也会更长 ZGC做了改进（动态区块大小） • G1NewSizePercent ○ 新生代最小比例，默认为5% • G1MaxNewSizePercent ○ 新生代最大比例，默认为60% • GCTimeRatio ○ GC时间建议比例，G1会根据这个值调整堆空间 • ConcGCThreads ○ 线程数量 • InitiatingHeapOccupancyPercent ○ 启动G1的堆空间占用比例 练习题 1. -XX:MaxTenuringThreshold控制的是什么？ A: 对象升入老年代的年龄 B: 老年代触发FGC时的内存垃圾比例 2. 生产环境中，倾向于将最大堆内存和最小堆内存设置为：（为什么？） A: 相同 B：不同 3. JDK1.8默认的垃圾回收器是： A: ParNew + CMS B: G1 C: PS + ParallelOld D: 以上都不是 4. 什么是响应时间优先？ 5. 什么是吞吐量优先？ 6. ParNew和PS的区别是什么？ 7. ParNew和ParallelOld的区别是什么？（年代不同，算法不同） 8. 长时间计算的场景应该选择：A：停顿时间 B: 吞吐量 9. 大规模电商网站应该选择：A：停顿时间 B: 吞吐量 10. HotSpot的垃圾收集器最常用有哪些？ 11. 常见的HotSpot垃圾收集器组合有哪些？ 12. JDK1.7 1.8 1.9的默认垃圾回收器是什么？如何查看？ 13. 所谓调优，到底是在调什么？ 14. 如果采用PS + ParrallelOld组合，怎么做才能让系统基本不产生FGC 15. 如果采用ParNew + CMS组合，怎样做才能够让系统基本不产生FGC 1.加大JVM内存 2.加大Young的比例 3.提高Y-O的年龄 4.提高S区比例 5.避免代码内存泄漏 16. G1是否分代？G1垃圾回收器会产生FGC吗？ 17. 如果G1产生FGC，你应该做什么？ 1. 扩内存 2. 提高CPU性能（回收的快，业务逻辑产生对象的速度固定，垃圾回收越快，内存空间越大） 3. 降低MixedGC触发的阈值，让MixedGC提早发生（默认是45%） 18. 问：生产环境中能够随随便便的dump吗？ 1. 小堆影响不大，大堆会有服务暂停或卡顿（加live可以缓解），dump前会有FGC 19. 问：常见的OOM问题有哪些？ 1. 栈 堆 MethodArea 直接内存 参考资料: 1. https://blogs.oracle.com/jonthecollector/our-collectors 2. https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html 3. http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp 4. JVM调优参考文档：https://docs.oracle.com/en/java/javase/13/gctuning/introduction-garbage-collection-tuning.html#GUID-8A443184-7E07-4B71-9777-4F12947C8184 5. https://www.cnblogs.com/nxlhero/p/11660854.html 在线排查工具 6. https://www.jianshu.com/p/507f7e0cc3a3 arthas常用命令 7. Arthas手册： 1. 启动arthas java -jar arthas-boot.jar 2. 绑定java进程 3. dashboard命令观察系统整体情况 4. help 查看帮助 5. help xx 查看具体命令帮助 8. jmap命令参考： https://www.jianshu.com/p/507f7e0cc3a3 1. jmap -heap pid 2. jmap -histo pid 3. jmap -clstats pid
CMS日志分析
执行命令：java -Xms20M -Xmx20M -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC T15_FullGC_Problem01
[GC (Allocation Failure) [ParNew: 6144K->640K(6144K), 0.0265885 secs] 6585K->2770K(19840K), 0.0268035 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
ParNew：年轻代收集器
6144->640：收集前后的对比
（6144）：整个年轻代容量
6585 -> 2770：整个堆的情况
（19840）：整个堆大小
[GC (CMS Initial Mark) [1 CMS-initial-mark: 7350K(13696K)] 9033K(19840K), 0.0018277 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
//7350K(13696K) : 老年代使用（最大）
//9033K(19840K) : 整个堆使用（最大）
[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.012/0.012 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
//这里的时间意义不大，因为是并发执行
[CMS-concurrent-preclean-start]
[CMS-concurrent-preclean: 0.004/0.004 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
//标记Card为Dirty，也称为Card Marking
[GC (CMS Final Remark) [YG occupancy: 1682 K (6144 K)][Rescan (parallel) , 0.0015702 secs][weak refs processing, 0.0000247 secs][class unloading, 0.0004549 secs][scrub symbol table, 0.0006202 secs][scrub string table, 0.0000321 secs][1 CMS-remark: 7350K(13696K)] 9033K(19840K), 0.0028101 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
//STW阶段，YG occupancy:年轻代占用及容量
//[Rescan (parallel)：STW下的存活对象标记
//weak refs processing: 弱引用处理
//class unloading: 卸载用不到的class
//scrub symbol(string) table:
//cleaning up symbol and string tables which hold class-level metadata and
//internalized string respectively
//CMS-remark: 8511K(13696K): 阶段过后的老年代占用及容量
//10108K(19840K): 阶段过后的堆占用及容量
[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
//标记已经完成，进行并发清理
[CMS-concurrent-reset-start]
[CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
//重置内部结构，为下次GC做准备
G1日志详解
执行命令：java -Xms20M -Xmx20M -XX:+PrintGCDetails -XX:+UseG1GC T15_FullGC_Problem01
[GC pause (G1 Evacuation Pause) (young), 0.0016743 secs]
//young -> 年轻代 Evacuation-> 复制存活对象
//initial-mark 混合回收的阶段，这里是YGC混合老年代回收
[Parallel Time: 1.6 ms, GC Workers: 1]//一个GC线程
[GC Worker Start (ms): 105.0]
[Ext Root Scanning (ms): 0.6]
[Update RS (ms): 0.0]
[Processed Buffers: 0]
[Scan RS (ms): 0.0]
[Code Root Scanning (ms): 0.0]
[Object Copy (ms): 0.7]
[Termination (ms): 0.0]
[Termination Attempts: 1]
[GC Worker Other (ms): 0.0]
[GC Worker Total (ms): 1.4]
[GC Worker End (ms): 106.4]
[Code Root Fixup: 0.0 ms]
[Code Root Purge: 0.0 ms]
[Clear CT: 0.0 ms]
[Other: 0.1 ms]
[Choose CSet: 0.0 ms]
[Ref Proc: 0.0 ms]
[Ref Enq: 0.0 ms]
[Redirty Cards: 0.0 ms]
[Humongous Register: 0.0 ms]
[Humongous Reclaim: 0.0 ms]
[Free CSet: 0.0 ms]
[Eden: 3072.0K(3072.0K)->0.0B(3072.0K) Survivors: 0.0B->1024.0K Heap: 3072.0K(20.0M)->496.1K(20.0M)]
[Times: user=0.00 sys=0.00, real=0.00 secs]
//以下是混合回收其他阶段
[GC concurrent-root-region-scan-start]
[GC concurrent-root-region-scan-end, 0.0000062 secs]
[GC concurrent-mark-start]
//无法evacuation，进行FGC
[Full GC (Allocation Failure) 18M->18M(20M), 0.0591118 secs]
[Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 18.8M(20.0M)->18.8M(20.0M)], [Metaspace: 2456K->2456K(4400K)]
[Times: user=0.06 sys=0.00, real=0.06 secs]