一、JVM调优的监控方法
jvm在对进行问题排查，线程等关注问题，在理解jvm的内存分配和垃圾回收，java类的编译和加载等等理论知识的前提下要学会使用工具去观察jvm中的实际场景下的jvm的情况，这里有很多工具进行监控。
1）jdk的命令行工具（其中都是在jdk/bin目录下）
| 命令 | 全名 | 说明 |
| jps |
jvm process status tool |
显示制定系统内所有的hotspot虚拟机进程 |
| jstat | jvm statistics monitoring tool | 虚拟机统计信息监视工具 |
| jinfo | java配置信息工具 | |
| jmap | java内存映像工具 | |
| jhat | 虚拟机堆转储快照分析工具 | |
| jstack | java对战跟踪工具 | |
| HSDIS | JIT生成代码反汇编 |
2）jdk的可视化工具
| 命令 | 全名 | 说明 |
| JConsole |
jvm process status tool |
java监视与管理控制台 |
| VisualVM | jvm statistics monitoring tool | 多合一故障处理工具 |
3）第三方监控工具
JProfiler
二、调优的方法
1）堆信息查看
可查看堆空间大小分配（年轻代、年老代、持久代分配），提供即时的垃圾回收功能，垃圾监控（长时间监控回收情况），看堆内类、对象信息，查看数量、类型等，对象引用情况查看 。
有了堆信息查看方面的功能，我们一般可以顺利解决以下问题：
年老代年轻代大小划分是否合理
内存泄漏
垃圾回收算法设置是否合理
2）线程监控
系统线程数量。各个线程都处在什么样的状态下，查看线程内部运行情况，死锁检查 ，热点分析，快照
|
CPU热点：检查系统哪些方法占用的大量CPU时间 内存热点：检查哪些对象在系统中数量最大（一定时间内存活对象和销毁对象一起统计） 这两个东西对于系统优化很有帮助。我们可以根据找到的热点，有针对性的进行系统的瓶颈查找和进行系统优化，而不是漫无目的的进行所有代码的优化。 快照 快照是系统运行到某一时刻的一个定格。在我们进行调优的时候，不可能用眼睛去跟踪所有系统变化，依赖快照功能，我们就可以进行系统两个不同运行时刻，对象（或类、线程等）的不同，以便快速找到问题 举例说，我要检查系统进行垃圾回收以后，是否还有该收回的对象被遗漏下来的了。那么，我可以在进行垃圾回收前后，分别进行一次堆情况的快照，然后对比两次快照的对象情况。 |
3）内存泄漏检查
内存泄漏一般可以理解为系统资源（各方面的资源，堆、栈、线程等）在错误使用的情况下，导致使用完毕的资源无法回收（或没有回收），从而导致新的资源分配请求无法完成，引起系统错误。内存泄漏对系统危害比较大，因为他可以直接导致系统的崩溃。需要区别一下，内存泄漏和系统超负荷两者是有区别的，虽然可能导致的最终结果是一样的。内存泄漏是用完的资源没有回收引起错误，而系统超负荷则是系统确实没有那么多资源可以分配了（其他的资源都在使用）
年老代堆空间被占满java.lang.OutOfMemoryError: Java heap space
分析：所有堆空间都被无法回收的垃圾对象占满，虚拟机无法再在分配新空间。
解决方法：一般就是根据垃圾回收前后情况对比，同时根据对象引用情况（常见的集合对象引用）分析，基本都可以找到泄漏点。
持久代被占满java.lang.OutOfMemoryError: PermGen space
分析：Perm空间被占满。无法为新的class分配存储空间而引发的异常。这个异常以前是没有的，但是在Java反射大量使用的今天这个异常比较常见了。主要原因就是大量动态反射生成的类不断被加载，最终导致Perm区被占满。更可怕的是，不同的classLoader即便使用了相同的类，但是都会对其进行加载，相当于同一个东西，如果有N个classLoader那么他将会被加载N次。因此，某些情况下，这个问题基本视为无解。当然，存在大量classLoader和大量反射类的情况其实也不多。
解决方法： -XX:MaxPermSize=16m或者换用JDK，比如JRocket。
堆栈溢出：java.lang.StackOverflowError
分析：一般就是递归没返回，或者循环调用造成
线程堆栈满：Fatal: Stack size too small
分析：java中一个线程的空间大小是有限制的。JDK5.0以后这个值是1M。与这个线程相关的数据将会保存在其中。但是当线程空间满了以后，将会出现上面异常。
解决方法：增加线程栈大小。-Xss2m。但这个配置无法解决根本问题，还要看代码部分是否有造成泄漏的部分。
系统内存被占满：java.lang.OutOfMemoryError: unable to create new native thread
分析：这个异常是由于操作系统没有足够的资源来产生这个线程造成的。系统创建线程时，除了要在Java堆中分配内存外，操作系统本身也需要分配资源来创建线程。因此，当线程数量大到一定程度以后，堆中或许还有空间，但是操作系统分配不出资源来了，就出现这个异常了。分配给Java虚拟机的内存愈多，系统剩余的资源就越少，因此，当系统内存固定时，分配给Java虚拟机的内存越多，那么，系统总共能够产生的线程也就越少，两者成反比的关系。同时，可以通过修改-Xss来减少分配给单个线程的空间，也可以增加系统总共内生产的线程数。
解决方法：重新设计系统减少线程数量；线程数量不能减少的情况下，通过-Xss减小单个线程大小。以便能生产更多的线程。
三、jvm调优的一些参数
|
-Xmx:最大堆内存,如：-Xmx512m -Xms:初始时堆内存,如：-Xms256m -XX:MaxNewSize:最大年轻区内存 -XX:NewSize:初始时年轻区内存.通常为 Xmx 的 1/3 或 1/4。新生代 = Eden + 2 个 Survivor 空间。实际可用空间为 = Eden + 1 个 Survivor，即 90% -XX:MaxPermSize:最大持久带内存 -XX:PermSize:初始时持久带内存 -XX:+PrintGCDetails。打印 GC 信息 -XX:NewRatio 新生代与老年代的比例，如 –XX:NewRatio=2，则新生代占整个堆空间的1/3，老年代占2/3 -XX:SurvivorRatio 新生代中 Eden 与 Survivor 的比值。默认值为 8。即 Eden 占新生代空间的 8/10，另外两个 Survivor 各占 1/10 堆设置 -Xms:初始堆大小 -Xmx:最大堆大小 -XX:NewSize=n:设置年轻代大小 -XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4 -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5 -XX:MaxPermSize=n:设置持久代大小 收集器设置 -XX:+UseSerialGC:设置串行收集器 -XX:+UseParallelGC:设置并行收集器 -XX:+UseParalledlOldGC:设置并行年老代收集器 -XX:+UseConcMarkSweepGC:设置并发收集器 垃圾回收统计信息 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:filename 并行收集器设置 -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。 -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间 -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n) 并发收集器设置 -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。 -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。 |
四、JVM调优
1）新生代设置过小
一是新生代GC次数非常频繁，增大系统消耗；二是导致大对象直接进入旧生代，占据了旧生代剩余空间，诱发Full GC
2）新生代设置过大
一是新生代设置过大会导致旧生代过小（堆总量一定），从而诱发Full GC；二是新生代GC耗时大幅度增加
一般说来新生代占整个堆1/3比较合适
3）Survivor设置过小
导致对象从eden直接到达旧生代，降低了在新生代的存活时间
4）Survivor设置过大
导致eden过小，增加了GC频率
另外，通过-XX:MaxTenuringThreshold=n来控制新生代存活时间，尽量让对象在新生代被回收
由内存管理和垃圾回收可知新生代和旧生代都有多种GC策略和组合搭配，选择这些策略对于我们这些开发人员是个难题，JVM提供两种较为简单的GC策略的设置方式
1）吞吐量优先
JVM以吞吐量为指标，自行选择相应的GC策略及控制新生代与旧生代的大小比例，来达到吞吐量指标。这个值可由-XX:GCTimeRatio=n来设置
2）暂停时间优先
JVM以暂停时间为指标，自行选择相应的GC策略及控制新生代与旧生代的大小比例，尽量保证每次GC造成的应用停止时间都在指定的数值范围内完成。这个值可由-XX:MaxGCPauseRatio=n来设置