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 文件，借助工具分析哪 个对象非常多，基本就能定位到问题在那了
)
)
