这是传说中程序员的一天：
8:00 被第N遍虐心的闹铃从床上拉下，木然洗漱，泡沫挂嘴角；
9:00 插在地铁的沙丁鱼罐头里，和着韭菜香和汗臭，盲目的翻着朋友圈、公众号和技术论坛；
10:00 公司，嚼着油条，等电脑收完最后一封邮件，开始重复的日常工作，敲敲敲敲敲代码
12:00 外卖小哥的到来，宣布午饭娱乐时间，边吃鸡边吃鸡，然后窝个觉
14:00 睁眼，继续，回回回回回邮件，重复敲代码
16:00 被PM叫去撕撕撕撕撕撕需求、接着改代码
18:00 被leader叫去，催催催催催进度
19:00 被肚子提醒，订餐吃饭
21:00 撸撸撸撸撸完最后一行代码后，点上一支烟，等着bug来袭
23:00 到家，继续解bug到深夜夜夜夜夜夜夜，然后洗洗睡吧
看到这段文字有多少人感同身受？我中招了，浑浑噩噩的往复，默默看着理想老去，难道这是当初走上“攻城狮”道路时想要的生活？
行业内竞争越来越激烈，我们先来看看招聘需求的结构性变化：
Java的招聘总量在减少，但中高端职位数量从未减少，甚至还有增加的趋势，这说明行业变得成熟起来，但对我们Java同学们来讲，却不得不面对越来越严峻的挑战：不进则退的危机越发明显。
看看我们都遇到了什么：
好不容易得到了阿里P6/P7的面试机会，当被面试官问到JVM相关问题时，好看的面试官同学一张嘴：在讨论技术方案时：
看到这有多少人感同身受？我中招了，浑浑噩噩的往复，默默看着理想老去，难道这是当初走上“攻城狮”道路时想要的生活？
接下来，让我跟大家一起-深入理解JVM
一、JVM简介
JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。
Java语言的一个非常重要的特点就是跨平台性。而使用Java虚拟机是实现这一特点的关键。一般的高级语言如果要在不同的平台上运行，至少需要编译成不同的目标代码。而引入Java语言虚拟机后，Java语言在不同平台上运行时不需要重新编译。Java语言使用Java虚拟机屏蔽了与具体平台相关的信息，使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。Java虚拟机在执行字节码时，把字节码解释成具体平台上的机器指令执行。这就是Java的能够“一次编译，到处运行”的原因。
二、JVM内存管理模型
JVM内存结构主要又三大块：堆内存、方法区和栈。
1、堆内存（Heap）
对于大多数应用来说，Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。
Java堆内存中还可以细分为：年轻代和老年代。其中，年轻代又可以分为Eden区、From Survivor空间、To Survivor空间等。
如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。
2、方法区（Method Area）
方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应该是与Java堆区分开来。
对于习惯在HotSpot虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“永久代”（Permanent Generation），本质上两者并不等价，仅仅是因为HotSpot虚拟机的设计团队选择把GC分代收集扩展至方法区，或者说使用永久代来实现方法区而已。
Java虚拟机规范对这个区域的限制非常宽松，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是有必要的。
根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。
3、程序计数器（Program Counter Register）
程序计数器（Program Counter Register）是一块较小的内存空间，它的作用可以看做是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里（仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现），字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。
如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Natvie方法，这个计数器值则为空。
此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
4、JVM栈（JVM Stacks）
与程序计数器一样，Java虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它不等同于对象本身，根据不同的虚拟机实现，它可能是一个指向对象起始地址的引用指针，也可能指向一个代表对象的句柄或者其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。
其中64位长度的long和double类型的数据会占用2个局部变量空间（Slot），其余的数据类型只占用1个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
在Java虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常。如果虚拟机栈可以动态扩展（当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常。
5、本地方法栈（Native Method Stacks）
本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的Native方法服务。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机（譬如Sun HotSpot虚拟机）直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。
三、JVM内存分配机制JVM内存≈Heap(堆内存)+PermGen(方法区)+Thrend(栈)
Heap（堆内存）=Young（年轻代）+Old（老年代），官方文档建议整个年轻代占整个堆内存的3/8，老年代占整个堆内存的5/8，但是可以配置为其他比例。
Young（年轻代）=EdenSpace+FromSurvivor+ToSurvivor，Eden区与两个存活区的内存大小比例是：8：1：1，同样可以配置为其他比例。
四、JVM垃圾回收机制1、new出来的对象先放在Eden区，Eden区放满后第一次触发Young GC（垃圾回收），把存活对象移到S1存活区。
2、第二次Eden区又满了，再次触发Young GC，把Eden区的存活对象移到S1存活区，把S0存活区的存活对象也移到S2存活区，这时S1存活区清空了。
3、第三次Eden区又满了，再次触发Young GC，把Eden区的存活对象移到S0存活区，把S1存活区的存活对象也移到S1存活区，这时S2存活区清空了。
4、这样S0和S1交替互换，轮流为清空，大大拉长了存活对象进入老年代的时间间隔。
类对象什么时候进入老年代：
a、大对象直接进入老年代：Eden区放不下直接进入老年代
b、长期存活的对象进入老年代：以Young GC次数进行判断的，默认次数15次后进入老年代
c、执行Young GC时，存活区放不下时，存活对象也直接进入老年代
5、一直这样循环往复直到老年代满了，触发Full GC。首先清除老年代中的没有引用的对象，再对Eden区进行GC，还会对持久代进行GC（持久代一般没什么可清理）
6、老年代里面放满以后，执行Full GC也释放不了内存空间，就会报内存溢出的错误了。
总结：
1、Young GC只发生在Eden区，Eden区是整个Java堆内存分配的入口，new对象优先分配到Eden区，Eden区满之后触发Young GC
2、Young GC触发后，然后它会判断Eden区的对象是否是存活的，如果是存活的则放到存活区，不是存活的则清除掉释放内存空间。
3、触发Full GC是虽然也清理了Eden区，但是Young GC次数不会+1，它是Full GC在干活。
什么时候触发Full GC：
a、老年代空间不足
b、持久代空间不足的时候也会触发Full GC
c、显示调用也可以触发Full GC，比如说RunTime.GC、System.GC
d、RMI框架，会产生大量的对象，会进行显示调用，触发Full GC
e、Young GC时的悲观策略dump live的内存信息时（jmap-dump:live）
4、执行Young GC和Full GC应用程序的所有线程都是暂停的、停止工作，但Full GC时间比较长
5、JVM调优的核心思想：
a、尽量减少Full GC的次数，或者说延长Full GC间隔时间。不要频繁触发Full GC，因为执行Full GC的时间比较长。
b、尽量减少Young GC执行的时间
五、JVM内存调优思路
首先需要注意的是在对JVM内存调优的时候不能只看操作系统级别Java进程所占用的内存，这个数值不能准确的反应堆内存的真实占用情况，因为GC过后这个值是不会变化的，因此内存调优的时候要更多地使用JDK提供的内存查看工具，比如JConsole和Java VisualVM。
对JVM内存的系统级的调优主要的目的是减少Young GC的频率和Full GC的次数，过多的GC和Full GC是会占用很多的系统资源（主要是CPU），影响系统的吞吐量。特别要关注Full GC，因为它会对整个堆内存进行整理，导致Full GC一般由于以下几种情况：
1、老年代空间不足
调优时尽量让对象在年轻代Young GC时被回收、让对象在年轻代多存活一段时间和不要创建过大的对象及数组避免直接在老年代创建对象
2、Pemanet Generation空间不足
增大Perm Gen空间，避免太多静态对象
3、System.gc()被显示调用
垃圾回收不要手动触发，尽量依靠JVM自身的机制，调优手段主要是通过控制堆内存的各个部分的比例和GC策略来实现。
下面来看看各部分比例不良设置会导致什么后果
1）年轻代设置过小
一是年轻代Young GC次数非常频繁，增大系统消耗
二是导致大对象直接进入老年代，占据了老年代剩余空间，诱发Full GC
2）年轻代设置过大
一是年轻代设置过大会导致老年代过小（堆总量一定），从而诱发Full GC
二是年轻代Young GC耗时大幅度增加
一般说来年轻代占整个堆内存的1/3比较合适
3）Survivor设置过小
导致对象从Eden区直接到达老年代，降低了在年轻代的存活时间
4）Survivor设置过大
导致Eden区过小，增加了Young GC频率
另外，通过-XX:MaxTenuringThreshold=n来控制年轻代存活时间，尽量让对象在年轻代被回收
六、垃圾回收策略
1、串行收集
串行收集使用单线程处理所有垃圾回收工作，因为无需多线程交互，而且效率比较高。但是，也无法使用多处理器的优势，所以串行收集适合单核处理器机器。当然，此收集器也可以用在小数据量（100M左右）情况下的多核处理器机器上，可以使用-XX:+UseSerialGC打开。
2、并行收集
并行收集，对年轻代进行并行垃圾回收，因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用，使用-XX:+UseParallelGC.打开。并行收集器在J2SE5.0第六6更新上引入，在Java SE6.0中迕行了增强--可以对年老代进行并行收集。如果年老代不使用并发收集的话，默认是使用单线程进行垃圾回收，因此会制约扩展能力，老年代开启并发收集，使用-XX:+UseParallelOldGC打开。
使用-XX:ParallelGCThreads=
并行收集器可以进行如下配置：
最大垃圾回收暂停：指定垃圾回收时的最长暂停时间，通过-XX:MaxGCPauseMillis=
吞吐量：吞吐量为垃圾回收时间和非垃圾回收时间的比值，通过-XX:GCTimeRatio=
3、并发收集
并发收集可以保证大部分垃圾回收工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，并发收集器适合于对响应时间要求比较高的中、大规模应用，使用-XX:+UseConcMarkSweepGC打开。
并发收集器主要减少年老代的暂停时间，他在应用不停止的情况下使用独立的垃圾回收线程，跟踪可达对象。在每个年老代垃圾回收周期中，在收集初期并发收集器的过程中会对整个应用进行简短的暂停，在收集中还会再暂停一次。第二次暂停会比第一次稍长，在此过程中多个线程同时进行垃圾回收工作。并发收集器使用处理器换来短暂的停顿时间。在一个N核处理器的机器上，并发收集部分使用N/K个可用处理器进行回收，一般情况下1<=K<=N/4。在只有一个处理器的主机上使用并发收集器，设置为incremental mode模式也可获得较短的停顿时间。
浮动垃圾：由于在应用运行的同时进行垃圾回收，所以有些垃圾可能在垃圾回收进行完成时产生，这样就造成了“Floating Garbage”，这些垃圾需要在下次垃圾回收周期时才能回收掉。所以，并发收集器一般需要20%的预留空间用于这些浮劢垃圾。
并发模式失败：并发收集器在应用运行时进行收集，所以需要保证堆内存在垃圾回收的这段时间有足够的空间供程序使用，否则，垃圾回收还未完成，堆空间先满了。返种情况下将会发生“Concurrent Mode Failure”，此时整个应用将会暂停，进行垃圾回收。
启动并发收集器：因为并发收集在应用运行时进行收集，所以必须保证收集完成之前有足够癿内存空间供程序使用，否则会出现“Concurrent Mode Failure”。通过设置-XX:CMSInitiatingOccupancyFraction=
小结：
串行处理器：
- 适用情况：数据量比较小（100M左右），单处理器下并且对响应时间无要求的应用。
- 缺点：只能用亍小型应用
并行处理器：
- 适用情况：对吞吐量有高要求，多CPU、对应用响应时间无要求的中、大型应用。举例：后台处理、科学计算。
- 缺点：垃圾收集过程中应用响应时间可能加长。
并发处理器：
- 适用情况：对响应时间有高要求，多CPU、对应用响应时间有较高要求的中、大型应用。举例：Web服务器/应用服务器、电信交换、集成开发环境。
七、JVM内存监控工具
1、命令行工具
- jmap：用于生成堆快照（heapdump），堆栈中的对象的统计信息，包含类、实例数量和合计容量。
- jstat：用于监控虚拟机的各种运行状态信息，如类的装载、内存、垃圾回收、JIT编译器等，在没有GUI的服务器上。
- jstack：用于JVM当前时刻的线程快照，又称threaddump文件，它是JVM当前每一条线程正在执行的堆栈信息的集合。
- jstatd：是一个基于RMI（Remove Method Invocation）的服务程序，它用于监控基于HotSpot的JVM中资源的创建及销毁，并且提供了一个远程接口允许远程的监控工具连接到本地的JVM执行命令。
- jdb：用来对core文件和正在运行的Java进程进行实时地调试，里面包含了丰富的命令帮助您进行调试。
- jhat：用来分析dump文件的一个微型的HTTP/HTML服务器，它能将生成的dump文件生成在线的HTML文件，让我们可以通过浏览器进行查阅。
- jinfo：实时查看虚拟机的各项参数信息，查看默认的参数信息。
- jps：参照Unix系统的取名规则命名的，而他的功能和ps的功能类似，可以列举正在运行的JAVA虚拟机进程并显示虚拟机执行的主类以及这些进程的唯一ID。
2、图形化工具
- jconsole：一个基于JMX的GUI工具，用于连接正在运行的JVM，它是Java自带的简单性能监控工具。
- jvisualvm：是Netbeans的profile子项目，已在JDK6.0 update 7 中自带(bin/jvisualvm.exe)，能够监控线程，内存情况，查看方法的CPU时间和内存中的对象，已被GC的对象，反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的)。
- jprofiler：是一款Java的性能监控工具。可以查看当前应用的对象、对象引用、内存、CPU使用情况，线程运行情况（阻塞、等待等），同时可以查找哪个对象占用的内存比较多、哪个对象占用CPU处理的时间比较多。
JVM——当我们遇到这个挑战Java高薪躲不过的坎时，很多人都难逃被暴虐的命运。原因很多，即使我们制定了学习计划，也依然面临着这些问题
怎么破？
想要真正的把JVM搞懂，就需要对JVM有一个系统的知识体系的支撑的：
扎实的JVM基础知识、熟悉JVM内存结构、对GC垃圾回收有清晰的认知、JVM优化该考虑到的方面、对JMM的了解缺一不可。
我们先来看看大厂招聘的要求：这时候，你是缺少相关经验而毫无头绪，只能毫无存在感得听着，还是有着清晰的思路，娓娓道来，你愿意做哪个？
本文总结：
看到这有多少人感同身受？我中招了，浑浑噩噩的往复，默默看着理想老去，难道这是当初走上“攻城狮”道路时想要的生活？
对JVM感兴趣的朋友可以加入：
Java进阶架构技术群群号：529722406
在群内拿些资料视频以及文档，
主要交流Java互联网前沿技术性能调优 （Tomcat Nginx JVM） 分布式框架（并发编程 Zookeeper Netty dubbo Redis）微服务框架（ Spring Cloud Docker虚拟化 微服务架构 ）
谢谢！ 感谢关注，欢迎转发、