jdk自带的JVM调优工具
jvm监控分析工具一般分为两类，一种是jdk自带的工具，一种是第三方的分析工具。jdk自带工具一般在jdk bin目录下面，以exe的形式直接点击就可以使用，其中包含分析工具已经很强大，几乎涉及了方方面面，但是我们最常使用的只有两款：jconsole.exe和jvisualvm.exe；第三方的分析工具有很多，各自的侧重点不同，比较有代表性的：MAT(Memory Analyzer Tool)、GChisto等。
jconsole
Jconsole（Java Monitoring and Management Console）是从java5开始，在JDK中自带的java监控和管理控制台，用于对JVM中内存，线程和类等的监控，是一个基于JMX（java management extensions）的GUI性能监测工具。jconsole使用jvm的扩展机制获取并展示虚拟机中运行的应用程序的性能和资源消耗等信息。
直接在jdk/bin目录下点击jconsole.exe即可启动，界面如下:
在弹出的框中可以选择本机的监控本机的java应用，也可以选择远程的java服务来监控，如果监控远程服务需要在tomcat启动脚本中添加如下代码：
-Dcom.sun.management.jmxremote.port=6969 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
连接进去之后，就可以看到jconsole概览图和主要的功能：概述、内存、线程、类、VM、MBeans
- 概述，以图表的方式显示出堆内存使用量，活动线程数，已加载的类，CUP占用率的折线图，可以非常清晰的观察在程序执行过程中的变动情况。
- 内存，主要展示了内存的使用情况，同时可以查看堆和非堆内存的变化值对比，也可以点击执行GC来处罚GC的执行
- 线程，主界面展示线程数的活动数和峰值，同时点击左下方线程可以查看线程的详细信息，比如线程的状态是什么，堆栈内容等，同时也可以点击“检测死锁”来检查线程之间是否有死锁的情况。
- 类，主要展示已加载类的相关信息。
- VM 概要，展示JVM所有信息总览，包括基本信息、线程相关、堆相关、操作系统、VM参数等。
- Mbean,查看Mbean的属性，方法等。
VisualVM
简介
VisualVM 是一个工具，它提供了一个可视界面，用于查看 Java 虚拟机 (Java Virtual Machine, JVM) 上运行的基于 Java 技术的应用程序（Java 应用程序）的详细信息。VisualVM 对 Java Development Kit (JDK) 工具所检索的 JVM 软件相关数据进行组织，并通过一种使您可以快速查看有关多个 Java 应用程序的数据的方式提供该信息。您可以查看本地应用程序以及远程主机上运行的应用程序的相关数据。此外，还可以捕获有关 JVM 软件实例的数据，并将该数据保存到本地系统，以供后期查看或与其他用户共享。
VisualVM 是javajdk自带的最牛逼的调优工具了吧，也是我平时使用最多调优工具，几乎涉及了jvm调优的方方面面。同样是在jdk/bin目录下面双击jvisualvm.exe既可使用，启动起来后和jconsole 一样同样可以选择本地和远程，如果需要监控远程同样需要配置相关参数，主界面如下；
VisualVM可以根据需要安装不同的插件，每个插件的关注点都不同，有的主要监控GC，有的主要监控内存，有的监控线程等。
如何安装：
大家可能在这里会遇到安装不了的坑！！！！
解决：首先用浏览器浏览：https://visualvm.github.io/pluginscenters.html
其次从中找到自己的版本，我的是jdk1.8版本，我选择了第二个，复制它的地址
复制地址到上面的url中，就可以去查看可用插件进行下载了
这里以IntelliJ Platform (pid 15784)为例，双击后直接展开，主界面展示了系统和jvm两大块内容，点击右下方jvm参数和系统属性可以参考详细的参数信息.
因为VisualVM的插件太多，我这里主要介绍三个我主要使用几个：监控、线程、Visual GC
监控的主页其实也就是，cpu、内存、类、线程的图表
线程和jconsole功能没有太大的区别
Visual GC 是常常使用的一个功能，可以明显的看到年轻代、老年代的内存变化，以及gc频率、gc的时间等。
以上的功能其实jconsole几乎也有，VisualVM更全面更直观一些，另外VisualVM非常多的其它功能，可以分析dump的内存快照，dump出来的线程快照并且进行分析等，还有其它很多的插件大家可以去探索
JVM垃圾回收
JVM的新生代分为三个区域，一个Eden区和两个Survivor区，它们之间的比例为（8：1：1），这个比例也是可以修改的。通常情况下，对象主要分配在新生代的Eden区上，少数情况下也可能会直接分配在老年代中。Java虚拟机每次使用新生代中的Eden和其中一块Survivor（From），在经过一次Minor GC后，将Eden和Survivor中还存活的对象一次性地复制到另一块Survivor空间上（这里使用的复制算法进行GC），最后清理掉Eden和刚才用过的Survivor（From）空间。将此时在Survivor空间存活下来的对象的年龄设置为1，以后这些对象每在Survivor区熬过一次GC，它们的年龄就加1，当对象年龄达到某个年龄（默认值为15）时，就会把它们移到老年代中。
在新生代中进行GC时，有可能遇到另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象，这些对象将直接通过分配担保机制进入老年代；
1. 新生代(Young Generation)：也有叫做年轻代的，这里使用《深入理解JAVA虚拟机》中的叫法，下同。
其实看名称就能看出一些，一般情况下，新创建的对象都会存放到新生代中(大对象除外)。
新生代中对象的特点是：很快就会被GC回收掉的或者不是特别大的对象。
为了方便垃圾收集，新生代又分出了一个Eden区，两个 Survivor区。
JVM 每次只会使用 Eden区 和其中的一块 Survivor 区域来为对象服务，另一块Survivor区域是空的，用于垃圾回收。
举个例子，第一次回收的时候，虚拟机会将 Eden区+Survivor（from）区域的存活对象复制到Survivor（to）上（存活对象小于Survivor（to）的空间），清空Survivor（from），虚拟机使用Eden区+Survivor（to）；
第二次回收的时候，虚拟机再将Eden区+Survivor（to）存活的对象复制到Survivor（from）。
这三个区域默认情况下是按照8：1：1分配，也可以手动配置。
2. Eden区
Eden区位于Java堆的新生代，是新对象分配内存的地方，由于堆是所有线程共享的，因此在堆上分配内存需要加锁。而Sun JDK为提升效率，会为每个新建的线程在Eden上分配一块独立的空间由该线程独享，这块空间称为TLAB（Thread Local Allocation Buffer）。在TLAB上分配内存不需要加锁，因此JVM在给线程中的对象分配内存时会尽量在TLAB上分配。如果对象过大或TLAB用完，则仍然在堆上进行分配。如果Eden区内存也用完了，则会进行一次Minor GC（young GC）。
3.Survival from to
Survival区与Eden区相同都在Java堆的年轻代。Survival区有两块，一块称为from区，另一块为to区，这两个区是相对的，在发生一次Minor GC后，from区就会和to区互换。在发生Minor GC时，Eden区和Survivalfrom区会把一些仍然存活的对象复制进Survival to区，并清除内存。Survival to区会把一些存活得足够旧的对象移至年老代。
4. 老年代（Old Generation）：在新生代每进行一次垃圾收集后，就会给存活的对象“加1岁”，当年龄达到一定数量的时候就会进入老年代（默认是15,可以通过-XX：MaxTenuringThreshold来设置）。
另外，比较大的对象也会进入老年代，可以-XX：PretenureSizeThreshold进行设置。
如-XX：PretenureSizeThreshold3M，那么大于3M的对象就会直接就进入老年代。
因此，老年代中存放的都是一些生命周期较长的对象或者特别大的对象。
5. 永久代（Permanent Generation ）：即JVM的方法区。在这里存放着一些被虚拟机加载的类信息（别忘了还有动态生成的类）的静态文件，这就导致了这个区中的东西比老年代和新生代更不容易回收。
永久代大小通过-XX:MaxPermSize=<N>进行设置。
6. 元空间（Metaspace）：从JDK 8开始，Java开始使用元空间取代永久代，元空间并不在虚拟机中，而是直接使用本地内存。
那么，默认情况下，元空间的大小仅受本地内存限制。当然，也可以对元空间的大小手动的配置。
JVM常见的垃圾回收机制
Minor GC
Minor GC指新生代GC，即发生在新生代（包括Eden区和Survivor区）的垃圾回收操作，当新生代无法为新生对象分配内存空间的时候，会触发Minor GC。因为新生代中大多数对象的生命周期都很短，所以发生Minor GC的频率很高，虽然它会触发stop-the-world，但是它的回收速度很快。
Major GC
Major GC清理Tenured区，用于回收老年代，出现Major GC通常会出现至少一次Minor GC。
Full GC
Full GC是针对整个新生代、老生代、元空间（metaspace，java8以上版本取代perm gen）的全局范围的GC。Full GC不等于Major GC，也不等于Minor GC+Major GC，发生Full GC需要看使用了什么垃圾收集器组合，才能解释是什么样的垃圾回收。
复制算法：
将区域分成两部分，其中一部分作为保留空间，另一部分作为使用空间、当发生垃圾回收时，首先检查使用空间里有哪些对象是存活的，检查完之后把存活的对象复制到保留空间（这样复制过来的好处是减少了内存碎片，如果直接在使用空间清除的话，那空间会很零散）里，然后清洗使用空间。
Survivor的存在意义，就是减少被送到老年代的对象，进而减少Full GC的发生，Survivor的预筛选保证，只有经历（默认）15次Minor GC还能在新生代中存活的对象，才会被送到老年代。
为什么要设置两个Survivor区
设置两个Survivor区最大的好处就是解决了碎片化，下面我们来分析一下。
为什么一个Survivor区不行？第一部分中，我们知道了必须设置Survivor区。假设现在只有一个survivor区，我们来模拟一下流程：
刚刚新建的对象在Eden中，一旦Eden满了，触发一次Minor GC，Eden中的存活对象就会被移动到Survivor区。这样继续循环下去，下一次Eden满了的时候，问题来了，此时进行Minor GC，Eden和Survivor各有一些存活对象，如果此时把Eden区的存活对象硬放到Survivor区，很明显这两部分对象所占有的内存是不连续的，也就导致了内存碎片化。
我绘制了一幅图来表明这个过程。其中色块代表对象，白色框分别代表Eden区（大）和Survivor区（小）。Eden区理所当然大一些，否则新建对象很快就导致Eden区满，进而触发Minor GC，有悖于初衷。
碎片化带来的风险是极大的，严重影响JAVA程序的性能。堆空间被散布的对象占据不连续的内存，最直接的结果就是，堆中没有足够大的连续内存空间，接下去如果程序需要给一个内存需求很大的对象分配内存。。。画面太美不敢看。。。这就好比我们爬山的时候，背包里所有东西紧挨着放，最后就可能省出一块完整的空间放相机。如果每件行李之间隔一点空隙乱放，很可能最后就要一路把相机挂在脖子上了。
那么，顺理成章的，应该建立两块Survivor区，刚刚新建的对象在Eden中，经历一次Minor GC，Eden中的存活对象就会被移动到第一块survivor space S0，Eden被清空；等Eden区再满了，就再触发一次Minor GC，Eden和S0中的存活对象又会被复制送入第二块survivor space S1（这个过程非常重要，因为这种复制算法保证了S1中来自S0和Eden两部分的存活对象占用连续的内存空间，避免了碎片化的发生）。S0和Eden被清空，然后下一轮S0与S1交换角色，如此循环往复。如果对象的复制次数达到16次，该对象就会被送到老年代中。下图中每部分的意义和上一张图一样，就不加注释了。
上述机制最大的好处就是，整个过程中，永远有一个survivor space是空的，另一个非空的survivor space无碎片。
那么，Survivor为什么不分更多块呢？比方说分成三个、四个、五个?显然，如果Survivor区再细分下去，每一块的空间就会比较小，很容易导致Survivor区满，因此，两块Survivor区是经过权衡之后的最佳方案。