JVM学习笔记-从底层了解程序运行(二)

阅读原文时间：2023年07月10日阅读：1

解决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  
![](https://article.cdnof.com/2307/5a799807-1b2a-4a51-a60a-8c54ee7fdc30.png)

eg.

waiting on condition [0xe7f5a000] (a java.lang.Object) 假如有一个进程中100个线程，很多线程都在waiting on ，一定要找到是哪个线程持有这把锁

怎么找？搜索jstack dump的信息，找，看哪个线程持有这把锁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  
    ![](https://article.cdnof.com/2307/df2166c0-62b2-4c8f-a586-e4b295fbaae9.png)

为什么需要在线排查？

在生产上我们经常会碰到一些不好排查的问题，例如线程安全问题，用最简单的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]

//标记已经完成，进行并发清理