JVM篇--JVM调优高频面试题

1 说一下 JVM 调优的工具？

JDK 自带了很多监控工具，都位于 JDK 的 bin 目录下，其中最常用的是jconsole 和 jvisualvm 这两款视图监控工具。
jconsole：用于对 JVM 中的内存、线程和类等进行监控；
jvisualvm：JDK 自带的全能分析工具，可以分析：内存快照、线程快照、程序死锁、监控内存的变化、gc 变化等

2 常用的 JVM 调优的参数都有哪些？

-Xms2g：初始化推大小为 2g；

-Xmx2g：堆最大内存为 2g；

-XX:NewRatio=4：设置年轻的和老年代的内存比例为 1:4；

-XX:SurvivorRatio=8：设置新生代 Eden 和 Survivor 比例为 8:2；

--XX:+UseParNewGC：指定使用 ParNew + Serial Old 垃圾回收器组合；

-XX:+UseParallelOldGC：指定使用 ParNew + ParNew Old 垃圾回收器组合；

-XX:+UseConcMarkSweepGC：指定使用 CMS + Serial Old 垃圾回收器组

合；

-XX:+PrintGC：开启打印 gc 信息；

-XX:+PrintGCDetails：打印 gc 详细信息。

3 线上服务 CPU 占用过高怎么排查？

首先针对cpu占用过高，肯定是某个程序长期占用了cpu资源导致的

所以针对这个问题

首先可以用top命令找出占用cpu比较高的进程
再根据进程找出占用比较高的线程即通过top -Hp 进程id 获取进程下的线程占用资源情况
找到对应线程后，打印线程的堆栈信息，这里需要注意需要把线程id转换成16进制，然后通过jstack PID 打印线程的堆栈信息
最后根据线程的堆栈信息定位到具体业务方法进行排查
需要注意的是看是否有线程长时间的 watting 或 blocked

4 内存飙高问题怎么排查？

首先我们要知道，内存飚高如果是发生在 java 进程上，一般是因为创建了大量对象所导致，而如果持续飚高意味着垃圾回收跟不上对象创建的速度，或者内存泄露导致对象无法回收

针对这种情况

1 先打印gc的情况，即通过jstat -gc PID 1000 查看 GC 次数，时间等信息，看看对象的GC 次数是否频繁，而且每次回收的内存空间是否正常，如果说每次回收的内存都很少，GC非常频繁那么可能是因为内存泄露导致的

2 导出堆内存文件快照

即可以通过 jmap -dump 导出堆内存信息到文件

3 使用 visualVM 对 dump 文件进行离线分析，找到占用内存高的对象，再找到创建该对象的业务代码位置，从代码和业务场景中定位具体问题

5 有没有遇到过内存泄漏问题？又该如何定位解决？

我们的确遇到过内存泄露，但其实在具体的表现上，可能是先出现以下这几种情况

应用程序长时间连续运行时性能严重下降
CPU 使用率飙升，甚至到 100%
频繁 Full GC，各种报警，例如接口超时报警等
应用程序抛出 OutOfMemoryError 错误
应用程序偶尔会耗尽连接对象
也就是说内存泄露往往会伴随着频繁的fullGC,以及cpu使用率飙升，这种情况我们就需要通过查看 Full GC 入手
具体来看就是用上面的线上服务 CPU 占用过高怎么排查的思路来解决
包括
1）使用 jps 查看运行的 Java 进程 ID
2）使用top -p [pid] 查看进程使用 CPU 和 MEM 的情况
3）使用 top -Hp [pid] 查看进程下的所有线程占 CPU 和 MEM 的情况
4）将线程 ID 转换为 16 进制：printf "%x\n" [pid]，输出的值就是线程栈信息中的 nid。例如：printf "%x\n" 29471，换行输出 731f。
5）抓取线程栈：jstack 29452 > 29452.txt，可以多抓几次做个对比。

之后我们还需要通过jstat 命令输出gc的信息，即查看 YGC 和 Full GC 次数。通常会出现 YGC 不增加或增加缓慢，而 Full GC 增加很快。如果发现 Full GC 次数太多，就很大概率存在内存泄漏了，然后可以用 jmap -dump 生成 dump 文件，借助工具分析哪个对象非常多，基本就能定位到问题在那了