前言
性能优化专题共计四个部分，分别是：
- Tomcat 性能优化
- MySql 性能优化
- JVM 性能优化
- 性能测试
本节是性能优化专题第二部分 —— JVM 性能优化篇，共计六个小节，分别是：
- JVM介绍与入门
- 类文件讲解
- 字节码执行引擎
- GC算法与调优
- JVM的内存模型与锁优化
- Linux性能监控与调优
通过这六节的学习，你将学到：
➢ 了解JVM内存模型以及每个分区详解。
➢ 熟悉运行时数据区，特别是堆内存结构和特点。
➢ 熟悉GC三种收集方法的原理和特点。
➢ 熟练使用GC调优工具，快速诊断线上问题。
➢ 生产环境CPU负载升高怎么处理？
➢ 生产环境给应用分配多少线程合适？
➢ JVM字节码是什么东西？
运行时数据区和内存模型
前面我们提到了装载(Load)的概念，即查找和导入Class文件。
(1)通过一个类的全限定名获取定义此类的二进制字节流
(2)将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
(3)在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口
可以看到，在装载阶段的第(2),(3)步可以发现有运行时数据，堆，方法区等名词。
初步认识两者关系
Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干不同数据区域。这里就涉及到一个概念，内存模型。
Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从
内存中取出变量这样的底层细节。
…
这里所讲的主内存、工作内存与Java内存区域中的Java堆、栈、方法区等并不是同一层次的内存划分，这两
者基本上是没有关系的。如果两者一定要勉强对应起来，从变量、主内存、工作内存的定义看，主内存主要
对应于Java堆中的对象实例数据部分，而工作内存则对应了虚拟机栈中部分区域。
运行时数据区(Run-Time Data Areas)
说白了就是类文件被类装载器装载进来之后，类中的内容(比如变量，常量，方法，对象等这些数据得要有个去处，也就是要存储起来，存储的位置肯定是在Java申请的内存中)
官网概括
https://docs.oracle.com/javase/specs/jvms/se8/html/index.html
The Java Virtual Machine defines various run-time data areas that are used during execution of a program. Some of these data areas are created on Java Virtual Machine start-up and are destroyed only when the Java Virtual Machine exits. Other data areas are per thread. Per-thread data areas are created when a thread is created and destroyed when the thread exits.
Java虚拟机定义了在程序执行期间使用的各种运行时数据区域。其中一些数据区域是在Java虚拟机启动时创建的，仅在Java虚拟机退出时才被销毁。其他数据区域是每个线程的。在创建线程时创建每个线程的数据区域，在线程退出时销毁每个数据区域。
图解
各个组件的理解
Method Area(方法区)
方法区是各个线程共享的内存区域，在虚拟机启动时创建。
用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却又一个别名叫做到 Non-Heap(非堆)，目的是与Java
堆区分开来。
当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。
The Java Virtual Machine has a method area that is shared among all Java Virtual Machine threads.
Java虚拟机具有一个在所有Java虚拟机线程之间共享的方法区域。
The method area is created on virtual machine start-up.
方法区域是在虚拟机启动时创建的。
If memory in the method area cannot be made available to satisfy an allocation request, the Java Virtual Machine throws an OutOfMemoryError.
如果无法使方法区域中的内存可用以满足分配请求，则Java虚拟机将引发OOM异常。
此时回看装载阶段的第2步：(2)将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
如果这时候把从Class文件到装载的第(1)和(2)步合并起来理解的话，可以画个图：
值得说明的是：
- 方法区在JDK 8中就是Metaspace，在JDK6或7中就是Perm Space
- Run-Time Constant Pool
Each run-time constant pool is allocated from the Java Virtual Machine’s method area.
Class文件中除了有类的版本、字段、方法、接口等描述 信息外，还有一项信息就是常量池，用于存放编译时期生
成的各种字面量和符号引用，这部分内容将在类加载后进 入方法区的运行时常量池中存放。
Heap(堆)
Java堆是Java虚拟机所管理内存中最大的一块，在虚拟机启动时创建，被所有线程共享。
Java对象实例以及数组都在堆上分配。
The Java Virtual Machine has a heap that is shared among all Java Virtual Machine threads.
Java虚拟机具有一个在所有Java虚拟机线程之间共享的堆。
The heap is created on virtual machine start-up.
堆是在虚拟机启动时创建的。
If a computation requires more heap than can be made available by the automatic storage management system, the Java Virtual Machine throws an OutOfMemoryError.
如果计算需要的堆多于自动存储管理系统可以提供的堆，则Java虚拟机将引发OutOfMemoryError。
此时回看装载阶段的第3步：(3)在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口
此时装载(1)(2)(3)的图可以改动一下:
Java Virtual Machine Stacks(虚拟机栈)
经过上面的分析，类加载机制的装载过程已经完成，后续的链接，初始化也会相应的生效。
假如目前的阶段是初始化完成了，后续做啥呢？肯定是Use使用咯，不用的话这样折腾来折腾去有什么意
义？那怎样才能被使用到？换句话说里面内容怎样才能被执行？比如通过主函数main调用其他方法，这种方
式实际上是main线程执行之后调用的方法，即要想使用里面的各种内容，得要以线程为单位，执行相应的方
法才行。
那一个线程执行的状态如何维护？一个线程可以执行多少个方法？这样的关系怎么维护呢？
虚拟机栈是一个线程执行的区域，保存着一个线程中方法的调用状态。换句话说，一个Java线程的运行状态，由一
个虚拟机栈来保存，所以虚拟机栈肯定是线程私有的，独有的，随着线程的创建而创建。
每一个被线程执行的方法，为该栈中的栈帧，即每个方法对应一个栈帧。
调用一个方法，就会向栈中压入一个栈帧；一个方法调用完成，就会把该栈帧从栈中弹出。
Each Java Virtual Machine thread has a private Java Virtual Machine stack, created at the same time as the thread.
每个Java虚拟机线程都有一个私有Java虚拟机堆栈，与该线程同时创建
画图理解栈和栈帧
栈帧：每个栈帧对应一个被调用的方法，可以理解为一个方法的运行空间。
A frame is used to store data and partial results, as well as to perform dynamic linking, return values for methods, and dispatch exceptions.
栈帧用于存储数据和部分结果，以及执行动态链接，方法的返回值和调度异常。
A new frame is created each time a method is invoked. A frame is destroyed when its method invocation completes, whether that completion is normal or abrupt (it throws an uncaught exception).
每次调用方法时都会创建一个新栈帧。当栈帧的方法调用完成时，无论该框架是正常的还是突然的（它引发未捕获的异常），栈帧都会被销毁。
Note that a frame created by a thread is local to that thread and cannot be referenced by any other thread.
请注意，由线程创建的栈帧在该线程本地，并且不能被任何其他线程引用。
每个栈帧中包括局部变量表(Local Variables)、操作数栈(Operand Stack)、指向运行时常量池的引用(A reference
to the run-time constant pool)、方法返回地址(Return Address)和附加信息。
局部变量表:方法中定义的局部变量以及方法的参数存放在这张表中 局部变量表中的变量不可直接使用，如需要使用的话，必须通过相关指令将其加载至操作数栈中作为操作数使用。
操作数栈:以压栈和出栈的方式存储操作数的
动态链接:每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的 动态连接(Dynamic Linking)。
方法返回地址:当一个方法开始执行后,只有两种方式可以退出，一种是遇到方法返回的字节码指令；一种是遇见异常， 并且这个异常没有在方法体内得到处理。
The pc Register(程序计数器)
我们都知道一个JVM进程中有多个线程在执行，而线程中的内容是否能够拥有执行权，是根据CPU调度来
的。
假如线程A正在执行到某个地方，突然失去了CPU的执行权，切换到线程B了，然后当线程A再获得CPU执行
权的时候，怎么能继续执行呢？这就是需要在线程中维护一个变量，记录线程执行到的位置。
程序计数器占用的内存空间很小，由于Java虚拟机的多线程是通过线程轮流切换，并分配处理器执行时间的方式来
实现的，在任意时刻，一个处理器只会执行一条线程中的指令。因此，为了线程切换后能够恢复到正确的执行位
置，每条线程需要有一个独立的程序计数器(线程私有)。
如果线程正在执行Java方法，则计数器记录的是正在执行的虚拟机字节码指令的地址；
如果正在执行的是Native方法，则这个计数器为空。
The Java Virtual Machine can support many threads of execution at once. Each Java Virtual Machine thread has its own pc (program counter) register. At any point, each Java Virtual Machine thread is executing the code of a single method, namely the current method for that thread. If that method is not native, the pc register contains the address of the Java Virtual Machine instruction currently being executed. If the method currently being executed by the thread is native, the value of the Java Virtual Machine’s pc register is undefined. The Java Virtual Machine’s pc register is wide enough to hold a returnAddress or a native pointer on the specific platform.
Java虚拟机可以一次支持多个执行线程。每个Java虚拟机线程都有其自己的pc（程序计数器）寄存器。在任何时候，每个Java虚拟机线程都在执行单个方法的代码，即该线程的当前方法。如果该方法不是本机方法，则pc寄存器包含当前正在执行的Java虚拟机指令的地址。如果线程当前正在执行的方法是本地方法，则Java虚拟机的pc寄存器的值未定义。 Java虚拟机的pc寄存器足够宽，可以在特定平台上保存returnAddress或本机指针。
Native Method Stacks(本地方法栈)
如果当前线程执行的方法是Native类型的，这些方法就会在本地方法栈中执行。
内存模型
上面对运行时数据区描述了很多，其实重点存储数据的是堆和方法区(非堆)，所以内存的设计也着重从这两方面展
开(注意这两块区域都是线程共享的)。
对于虚拟机栈，本地方法栈，程序计数器都是线程私有的。
一块是非堆区，一块是堆区。 堆区分为两大块，一个是Old区，一个是Young区。 Young区分为两大块，一个是Survivor区（S0+S1），一块是Eden区。 Eden:S0:S1=8:1:1 S0和S1一样大，也可以叫From和To。
画个图理解一下:
根据之前对于Heap的介绍可以知道，一般对象和数组的创建会在堆中分配内存空间，关键是堆中有这么多区域，那一个对象的创建到底在哪个区域呢？
对象创建所在区域
比如有对象A，B，C等创建在Eden区，但是Eden区的内存空间肯定有限，比如有100M，假如已经使用了100M或者达到一个设定的临界值，这时候就需要对Eden内存空间进行清理，即垃圾收集(Garbage Collect)，这样的GC我们称之为Minor GC，Minor GC指得是Young区的GC。
经过GC之后，有些对象就会被清理掉，有些对象可能还存活着，对于存活着的对象需要将其复制到Survivor区，然后再清空Eden区中的这些对象。
Survivor区详解
由图解可以看出，Survivor区分为两块S0和S1，也可以叫做From和To。
在同一个时间点上，S0和S1只能有一个区有数据，另外一个是空的。
接着上面的GC来说，比如一开始只有Eden区和From中有对象，To中是空的。
此时进行一次GC操作，From区中对象的年龄就会+1，我们知道Eden区中所有存活的对象会被复制到To区，
From区中还能存活的对象会有两个去处。
若对象年龄达到之前设置好的年龄阈值，此时对象会被移动到Old区，没有达到阈值的对象会被复制到To
区。
此时Eden区和From区已经被清空(被GC的对象肯定没了，没有被GC的对象都有了各自的去处)。
这时候From和To交换角色，之前的From变成了To，之前的To变成了From。
也就是说无论如何都要保证名为To的Survivor区域是空的。
Minor GC会一直重复这样的过程，知道To区被填满，然后会将所有对象复制到老年代中。
Old区详解
从上面的分析可以看出，一般Old区都是年龄比较大的对象，或者相对超过了某个阈值的对象。
在Old区也会有GC的操作，Old区的GC我们称作为Major GC，每次GC之后还能存活的对象年龄也会+1，如果年龄
超过了某个阈值，就会被回收。
对象的生命周期
我是一个普通的Java对象,我出生在Eden区,在Eden区我还看到和我长的很像的小兄弟,我们在Eden区中玩了挺长时间。 有一天Eden区中的人实在是太多了,我就被迫去了Survivor区的“From”区,自从去了Survivor区,我就开始漂了,有时候 在Survivor的“From”区,有时候在Survivor的“To”区,居无定所。直到我18岁的时候,爸爸说我成人了,该去社会上闯闯 了。于是我就去了年老代那边,年老代里,人很多,并且年龄都挺大的,我在这里也认识了很多人。在年老代里,我生活了20年 (每次GC加一岁),然后被回收。
常见问题
如何理解Minor/Major/Full GC？
Minor GC:新生代 Major GC:老年代 Full GC:新生代+老年代
为什么需要Survivor区?只有Eden不行吗？
如果没有Survivor,Eden区每进行一次Minor GC,存活的对象就会被送到老年代。 这样一来，老年代很快被填满,触发Major GC(因为Major GC一般伴随着Minor GC,也可以看做触发了Full GC)。 老年代的内存空间远大于新生代,进行一次Full GC消耗的时间比Minor GC长得多。 执行时间长有什么坏处?频发的Full GC消耗的时间很长,会影响大型程序的执行和响应速度。
可能你会说，那就对老年代的空间进行增加或者较少咯。 假如增加老年代空间，更多存活对象才能填满老年代。虽然降低Full GC频率，但是随着老年代空间加大,一旦发生Full GC,执行所需要的时间更长。 假如减少老年代空间，虽然Full GC所需时间减少，但是老年代很快被存活对象填满,Full GC频率增加。
所以Survivor的存在意义,就是减少被送到老年代的对象,进而减少Full GC的发生,Survivor的预筛选保证,只有经历16 次Minor GC还能在新生代中存活的对象,才会被送到老年代。
为什么需要两个Survivor区？
最大的好处就是解决了碎片化。也就是说为什么一个Survivor区不行?第一部分中,我们知道了必须设置Survivor区。假设现在只有一个Survivor区,我们来模拟一下流程:
刚刚新建的对象在Eden中,一旦Eden满了,触发一次Minor GC,Eden中的存活对象就会被移动到Survivor区。这样继续循环下去,下一次Eden满了的时候,问题来了,此时进行Minor GC,Eden和Survivor各有一些存活对象,如果此时把Eden区的存活对象硬放到Survivor区,很明显这两部分对象所占有的内存是不连续的,也就导致了内存碎片化。
永远有一个Survivor space是空的,另一个非空的Survivor space无碎片。
新生代中Eden:S1:S2为什么是8:1:1？
新生代中的可用内存：复制算法用来担保的内存为9：1 可用内存中Eden：S1区为8：1 即新生代中Eden:S1:S2 = 8：1：1
复制算法: 现代的商业虚拟机都采用这种收集算法来回收新生代，IBM公司的专门研究表明，新生代中的对象大概
98%是“朝生夕死”的，所以并不需要按照1：1的比例来划分内存空间，而是将新生代内存分为一块较大的
Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor，当回收时，将Eden和
Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的
Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8：1，也就是每次新生代中可用内存空
间为整个新生代容量的90%（80%+10%）。如果新生代经过回收后，存活的对象超过10%，这样就导致
另外一块Survivor空间没有足够空间存放存活对象。此时，这些对象将直接通过分配担保机制进入老年
代。
写在最后
本节代码下载地址为：https://github.com/harrypottry/jvmDemo
更多架构知识，欢迎关注本套系列文章：Java架构师成长之路