JVM 读书笔记

它并不是虚拟机运行时数据区的一部分，也不是JAVA虚拟机规范中定义的内存区域。在JDK1.4中加入了NIO类，引入了一种基于通道(Channel)于缓冲区(Buffer)的I/O方式，他可以使用Native函数库直接分配堆外内存，然后通过一个存储在JAVA堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在JAVA堆中和Native堆中来回复制数据。

二、对象是否存活分析

引用计数法

给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就增加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。

优点：实现简单，判定的效率高
缺点：很难解决对象之间相互循环引用的问题。

可达性分析算法

通过一系列的称为“GC Roots”的对象作为起始点，从这些对象向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连，则证明此对象是不可用的。

在Java语言中，可作为GC Roots的对象包括以下几种：

虚拟机栈（栈帧中的本地变量表）中引用的对象
方法区中类静态属性引用的对象
方法区中常量引用的对象
本地方法栈中JNI（Nactive方法）引用的对象

三、垃圾收集算法

标记-清除算法

首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

缺点：

效率问题，标记和清除两个过程的效率都不高
空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存，而不得不提前触发另一次垃圾收集动作。

复制算法

将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完了，就将还存活的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

优点：

这样使得每次都是对整个半区进行内存回收。内存分配时也就不用考虑内存碎片的情况，只要移动栈堆顶指针，按顺序分配内存即可，实现简单，运行高效；

缺点：

将内存减少到原来的一半

新生代中98%的对象是朝生夕死的短生命周期对象，所以不需要将新生代划分为容量大小相等的两部分内存，而是将新生代分为Eden区，Survivor from和Survivor to三部分，其占新生代内存容量默认比例分别为8：1：1，其中Survivor from和Survivor to总有一个区域是空白，只有Eden和其中一个Survivor总共90%的新生代容量用于为新创建的对象分配内存，只有10%的Survivor内存浪费，当新生代内存空间不足需要进行垃圾回收时，仍然存活的对象被复制到空白的Survivor内存区域中，Eden和非空白的Survivor进行标记-清理回收，两个Survivor区域是轮换的。

新生代中98%情况下空白Survivor都可以存放垃圾回收时仍然存活的对象，2%的极端情况下，如果空白Survivor空间无法存放下仍然存活的对象时，使用内存分配担保机制，直接将新生代依然存活的对象复制到年老代内存中，同时对于创建大对象时，如果新生代中无足够的连续内存时，也直接在年老代中分配内存空间。

标记-整理算法

标记阶段是相同的标记出所有需要回收的对象，在标记完成之后不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，在移动过程中清理掉可回收的对象，这个过程叫做整理。

优点：

标记-整理算法相比标记-清除算法的优点是内存被整理以后不会产生大量不连续内存碎片问题
复制算法在对象存活率高的情况下就要执行较多的复制操作，效率将会变低，而在对象存活率高的情况下使用标记-整理算法效率会大大提高

分代收集算法

根据内存中对象的存活周期不同，将内存划分为几块，java的虚拟机中一般把内存划分为新生代和年老代。

新生代中，每次垃圾收集时发现有大批对象死去，只有少量存活，选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集

老生代因为对象存活率高，没有额外空间对它进行分配担保，就必须使用标记清除或者标记整理算法来进行回收。

当新创建对象时一般在新生代中分配内存空间，当新生代垃圾收集器回收几次之后仍然存活的对象会被移动到年老代内存中，当大对象在新生代中无法找到足够的连续内存时也直接在年老代中创建。

四、垃圾回收器

Serial收集器

Serial收集器是最基本、发展历史最悠久的收集器。是单线程的收集器。它在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集完成。

Serial收集器依然是虚拟机运行在Client模式下默认新生代收集器，对于运行在Client模式下的虚拟机来说是一个很好的选择。

ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The Worl、对象分配规则、回收策略等都与Serial 收集器完全一样。

ParNew收集器是许多运行在Server模式下的虚拟机中首选新生代收集器，其中有一个与性能无关但很重要的原因是，除Serial收集器之外，目前只有ParNew它能与CMS收集器配合工作。

注意：

并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行哎另一个CPU上。

Parallel Scavenge（并行回收）收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器

该收集器的目标是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可用高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

Parallel Scavenge收集器提供两个参数用于精确控制吞吐量，分别是控制最大垃圾收起停顿时间的

-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数

Parallel Scavenge收集器还有一个参数：-XX:+UseAdaptiveSizePolicy。这是一个开关参数，当这个参数打开后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数，只需要把基本的内存数据设置好（如-Xmx设置最大堆），然后使用MaxGVPauseMillis参数或GCTimeRation参数给虚拟机设立一个优化目标。

自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别

Serial Old 收集器

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记整理算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。

如果在Server模式下，主要两大用途：

在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用
作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用

Serial Old收集器的工作工程

Parallel Old 收集器

Parallel Old 是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器在1.6中才开始提供。

CMS收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求

CMS收集器是基于“标记-清除”算法实现的。它的运作过程相对前面几种收集器来说更复杂一些，整个过程分为4个步骤：

（1）初始标记

（2）并发标记

（3）重新标记

（4）并发清除

其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”.

CMS收集器主要优点：并发收集，低停顿。

CMS三个明显的缺点：

（1）CMS收集器对CPU资源非常敏感。CPU个数少于4个时，CMS对于用户程序的影响就可能变得很大，为了应付这种情况，虚拟机提供了一种称为“增量式并发收集器”的CMS收集器变种。所做的事情和单CPU年代PC机操作系统使用抢占式来模拟多任务机制的思想

（2）CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。在JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中蓝年代增长不是太快，可以适当调高参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能，在JDK1.6中，CMS收集器的启动阀值已经提升至92%。

（3）CMS是基于“标记-清除”算法实现的收集器，手机结束时会有大量空间碎片产生。空间碎片过多，可能会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前出发FullGC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数（默认就是开启的），用于在CMS收集器顶不住要进行FullGC时开启内存碎片合并整理过程，内存整理的过程是无法并发的，空间碎片问题没有了，但停顿时间变长了。虚拟机设计者还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction,这个参数是用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值为0，标识每次进入Full GC时都进行碎片整理）

G1收集器

G1收集器的优势：

（1）并行与并发

（2）分代收集

（3）空间整理（标记整理算法，复制算法）

（4）可预测的停顿（G1处处理追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经实现Java（RTSJ）的来及收集器的特征）

使用G1收集器时，Java堆的内存布局是整个规划为多个大小相等的独立区域（Region）,虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region的集合。

G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在真个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获取的空间大小以及回收所需要的时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的又来）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽量可能高的灰机效率

G1 内存“化整为零”的思路

在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会遗漏。

如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为一下步骤：

（1）初始标记

（2）并发标记

（3）最终标记

（4）筛选回收

五、内存分配及回收策略

对象优先在Eden上分配

一般情况下对象都是优先分配在Eden上，当Eden没有足够的空间进行分配时，jvm会发起一次Minor GC。如果还是没有足够的空间分配，后面还有另外的措施，下面会提到。

　设置虚拟机的偶记日志参数-XX:+PrintGCDetails，在垃圾回收的时候会打印内存的回收日志，并且在进程退出的时候会输出当前内存各区域的分配情况。下面来看下具体的例子，首先需要设置jvm的参数- Xms20m -Xmx20m -Xmn10m，这三个参数说明java堆大小为20M，且不可扩展，其中10M分配给新生代，剩下的10M分配给老年代。-XX:SurvivorRatio=8是jvm默认的新生代中Eden和Survivor比例，默认为8:1。原因是新生代中的对象98%都会在下一次GC的时候回收掉，所以很适合采用复制算法进行垃圾回收，所以新生代10M的内存中，8M是Eden，1M是Survivor，另外的1M是未使用配合复制算法的内存块，也是Survivor。

大对象直接分配在老年代上

大对象是指需要大量连续内存空间去存放的对象，类似于那种很长的字符串和数组。大对象对于虚拟机的内存分布来讲并不是好事，当遇到很多存活仅一轮的大对象jvm更加难处理，写代码的时候应该避免这样的题。虚拟机中提供了-XX:PretenureSizeThreshold参数，另大于这个值的对象直接分配到老年代，这样做的目的是为了避免在Eden区和Survivor区之间发生大量的内存copy，在之前讲过的垃圾回收算法复制算法有提到过，就不多说了。

长期存活的对象将进入老年代

虚拟机既然采用了分带收集的思想来管理内存，那内存回收就必须识别哪些对象应该放在新生代，哪些对象应该放在老年代。为了打到目的，jvm给每个对象定义了一个年龄计数器（Age）。如果对象在Eden出生并且能过第一次Minor GC后仍然存活，并且可以在Survivor存放的话，将被移动到Survivor中，并将对象的年龄设为1。对象每躲过一次Minor GC，年龄就会加1，当他的年龄超过一年的阈值的时候，该对象就会晋升到老年代。这个阈值jvm默认是15，可以通过-XX:MaxTenuringThreshold来设置。

动态对象年龄判定

为了能更好的适应不同程序的内存状态，虚拟机并不总是要求对象的年龄必须达到-XX:MaxTenuringThreshold所设置的值才能晋升到老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年区，无须达到-XX:MaxTenuringThreshold中的设置值。

空间分配担保

在发生Minor GC的时候，虚拟机会检测每次晋升到老年代的平均大小是否大于老年代的剩余空间，如果大于，则直接进行一次FUll GC。如果小于，则查看HandlerPromotionFailyre设置是否允许担保失败，如果允许那就只进行Minor GC，如果不允许则也要改进一次FUll GC。也就是说新生代Eden存不下改对象的时候就会将该对象存放在老年代。

Minor GC和FUll GC的区别：

新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为java对象大对数都是逃不过第一轮的GC，所以Minor GC使用很频繁，一般回收速度也比较快。

老年代GC（FULL GC/Major GC）：指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC（但非绝对，在ParallelScavenge收集器的收集策略中就有直接进行Major GC的选择过程）。Major GC的速度一般会比Minor GC慢10倍以上。

常用的jvm参数设置

1、-Xms：初始堆大小，默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制。

2、Xmx：最大堆大小，默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制。

3、-Xmn：年轻代大小(1.4or lator)，此处的大小是（eden+ 2 survivor space).与jmap -heap中显示的New gen是不同的。

整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。

增大年轻代后,将会减小年老代大小.此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

4、-XX:NewSize：设置年轻代大小(for 1.3/1.4)。

5、-XX:MaxNewSize：年轻代最大值(for 1.3/1.4)。

6、-XX:PermSize：设置持久代(perm gen)初始值。

7、-XX:MaxPermSize：设置持久代最大值。

8、-Xss：每个线程的堆栈大小，JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K.更具应用的线程所需内存大小进行调整.在相同物理内存下,减小这个值能生成更多的线程.但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。

9、-XX:NewRatio：年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代)，-XX:NewRatio=4表示年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5。Xms=Xmx并且设置了Xmn的情况下，该参数不需要进行设置。

10、-XX:SurvivorRatio： Eden区与Survivor区的大小比值，设置为8,则两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。

11、-XX:LargePageSizeInBytes：内存页的大小不可设置过大，会影响Perm的大小。

12、-XX:+DisableExplicitGC：关闭System.gc()

13、-XX:MaxTenuringThreshold：垃圾最大年龄，如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代. 对于年老代比较多的应用,可以提高效率.如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概率该参数只有在串行GC时才有效。

14、-XX:PretenureSizeThreshold：对象超过多大是直接在旧生代分配，单位字节新生代采用Parallel Scavenge GC时无效另一种直接在旧生代分配的情况是大的数组对象,且数组中无外部引用对象。

15、-XX:TLABWasteTargetPercent： TLAB占eden区的百分比。

六、jdk的命令行工具

jps：虚拟机进程状况工具

jps (JVM Process Status Tool), 可以列出正在运行的虚拟机进程，并显示虚拟机执行主类（Main Class,main()函数所在的类）名称以及这些进程的本地虚拟机唯一ID（Local Virtual Machine Identifier,LVMID）。

jps 命令格式：> jps [ options ] [hostid]

jps可以通过RMI协议查询开启了RMI服务的远程虚拟机进程状态，hostid为RMI注册表中注册的主机名。

jstat：虚拟机统计信息监视工具

jstat(JVM Statistics Monitoring Tool) 用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。

jstat 命令格式：

> jstat [option vmid [interval[s|ms] [count]] ]

如果是本地虚拟机进程，VMID与LVMID是一致的，如果是远程虚拟机进程，VMID的格式应当是：

> [protocol:][//] lvmid [@hostname[:port]/servername]

参数interval和count代表查询间隔和次数，如果省略这两个参数，说明只查询一次。假设需要每250毫秒查询一次进程2764垃圾收集状况，一共查询20次，那命令行如下：

> jstat -gc 2764 250 20

选项option代表这用户希望查询的虚拟机信息，主要分为3类：类装载、垃圾收集和运行期编译状况

jstat 执行样例

E ：Eden 新生代使用了6.2%空间

S0、S1：Survivor0、Survivor1 空

O： Old 老年代 41.42%空间

P：Permanent 永生代使用了47.20%空间

YGC： Young GC (Minor GC) 发生了16次

YGCT：Young GC Time 总耗时0.105秒

FGC：FULL GC 发生了3次

FGCT：FULL GC Time 总耗时0.577秒

jinfo：Java配置信息工具

jinfo(Configuration Info for Java)的作用是实时地查看和调整虚拟机各项参数。

使用jps的命令的-v参数可以查看虚拟机启动时显示指定的参数列表，但如果想知道未被显示指定的参数的系统默认值，除了去找资料外，就只能使用jinfo的-flag选项进行查询了（如果只限于JDK1.6或以上版本的话，使用java -XX:+PrintFlagsFinal查看参数默认值也是一个很好的选择），jinfo还可以使用-sysprops选项把虚拟机进程的System.getProperties()的内容打印出来。这个命令在JDK1.5时期已经随着Linux版的JDK发布，当时只提供了信息查询的功能，JDK1.6之后，jinfo在Windows和linux平台都有提供，并且加入了运行期修改参数的能力，可以使用-flag[+|-]name或-flag name=valule修改一部分运行期可写的虚拟机参数值。JDK1.6中，jinfo对于Windows平台的功能仍然有较大的限制，只提供了最基本的-flag选项。

jinfo 命令格式：

jinfo [option] pid

执行样例：查询CMSInitiatingOccupancyFraction参数值

> jinfo -flag CMSInitiatingOccupancyFraction 1444 -XX:CMSInitiatingOccupancyFraction-85

jmap：Java内存映像工具

jmap(Memory Map for Java) 命令用户堆转存储快照(一般称为heapdump或dump文件)。

如果不使用jmap命令，要想获取Java堆转储快照，还有一些比较“暴力”的手段：譬如加-XX：+HeapDumpOnOutOfMemoryError参数，可以让虚拟机在OOM异常出现之后自动生成dump文件，通过-XX：+HeapDumpOnCtrlBreak参数则可以使用[Ctrl]+[Break]键让虚拟机生成dump文件，又或者在Linux系统下通过Kill-3命令发送进程退出信号“吓唬”一下虚拟机，也能拿到dump文件。

jmap的作用并不仅仅是为了获取dump文件，它还可以查询finalize执行队列、Java堆和永久代的详细信息，如空间使用率、当前用的是哪种收集器等。和jinfo命令一样，jmap有不少功能在Windows平台下都是受限的，除了生成dump文件的-dump选项和用于查看每个类的实例、空间占用统计的-histo选项在所有操作系统都提供之外，其余选项都只能在Linux/Solaris下使用。

jmap 命令格式：

jmap [ option ] vmid

执行样例：生成一个正在运行的Eclipse的dump快照文件

> jmap -dump:format-=b,file=eclipse.bin 3500

Dumping heap to C:\User\....\eclipse.bin ...

Heap dump file created

jhat：虚拟机堆转储快照分析工具

jhat(JVM Heap Analysis Tool) 命令与jmap搭配使用，来分析jmap生成的堆转存储快照。

jhat内置了一个微型的HTTP/HTML服务器，生成dump文件的分析结果后，可以在浏览器中产看。

缺点：

分析工作是一个耗时而且消耗硬件资源的过程；
jhat的分享功能相对来说比较简陋

屏幕显示"Server is ready"的提示后，用户在浏览器中键入'http://localhost:7000'可以看到分析结果

jstack：Java堆栈跟踪工具

jstack(Stack Trace for Java) 命令用于生产虚拟机当前时刻的线程快照(一般称为threaddump 或者 javacore 文件)。

线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程死锁，死循环、请求外部资源导致的长时间等待等都是线程长时间停顿的常见原因。线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有相应的线程到底在后台做些什么事情，或者等待着什么资源。

jstack 命令格式：

jstatck [ option ] vmid

七、JVM调优

堆大小设置

JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统下，一般限制在1.5G~2G；64为操作系统对内存无限制。我在Windows Server 2003 系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m。

典型设置：

1、java -Xmx3550m -Xms3550m -Xmn2g -Xss128k

-Xmx3550m：设置JVM最大可用内存为3550M。

-Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。

-Xmn2g：设置年轻代大小为2G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。

-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。

2、java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0

-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5

-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6

-XX:MaxPermSize=16m:设置持久代大小为16m。

-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。

回收器选择

JVM给了三种选择：串行收集器、并行收集器、并发收集器，但是串行收集器只适用于小数据量的情况，所以这里的选择主要针对并行收集器和并发收集器。默认情况下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后，JVM会根据当前系统配置进行判断。

1、吞吐量优先的并行收集器

如上文所述，并行收集器主要以到达一定的吞吐量为目标，适用于科学技术和后台处理等。

典型配置：

（1）java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20

-XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。

-XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。

（2）java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC

-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。

（3）java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100

-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。

（4）java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy

-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。

2、响应时间优先的并发收集器

如上文所述，并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。

典型配置：

1、java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

-XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。

-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。

2、java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。

-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片

辅助信息

JVM提供了大量命令行参数，打印信息，供调试使用。主要有以下一些：

1、-XX:+PrintGC

输出形式：[GC 118250K->113543K(130112K), 0.0094143 secs]

[Full GC 121376K->10414K(130112K), 0.0650971 secs]

2、-XX:+PrintGCDetails

输出形式：[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]

[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]

3、-XX:+PrintGCTimeStamps -XX:+PrintGC：PrintGCTimeStamps可与上面两个混合使用

输出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]

4、-XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前，程序未中断的执行时间。可与上面混合使用

输出形式：Application time: 0.5291524 seconds

5、-XX:+PrintGCApplicationStoppedTime：打印垃圾回收期间程序暂停的时间。可与上面混合使用

输出形式：Total time for which application threads were stopped: 0.0468229 seconds

6、-XX:PrintHeapAtGC:打印GC前后的详细堆栈信息

输出形式：

34.702: [GC {Heap before gc invocations=7:

def new generation total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)

eden space 49152K, 99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)

from space 6144K, 55% used [0x221d0000, 0x22527e10, 0x227d0000)

to space 6144K, 0% used [0x21bd0000, 0x21bd0000, 0x221d0000)

tenured generation total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)

the space 69632K, 3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)

compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)

the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)

ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)

rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)

34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:

def new generation total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)

eden space 49152K, 0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)

from space 6144K, 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)

to space 6144K, 0% used [0x221d0000, 0x221d0000, 0x227d0000)

tenured generation total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)

the space 69632K, 4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)

compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)

the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)

ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)

rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)

}

, 0.0757599 secs]

-Xloggc:filename:与上面几个配合使用，把相关日志信息记录到文件以便分析。

常见配置汇总

1、堆设置

-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:设置持久代大小

2、收集器设置

-XX:+UseSerialGC:设置串行收集器

-XX:+UseParallelGC:设置并行收集器

-XX:+UseParalledlOldGC:设置并行年老代收集器

-XX:+UseConcMarkSweepGC:设置并发收集器

3、垃圾回收统计信息

-XX:+PrintGC

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:filename

4、并行收集器设置

-XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。

-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间

-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

5、并发收集器设置

-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。

-XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。

调优总结

1、年轻代大小选择

响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。

吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。

2、年老代大小选择

响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：

（1）并发垃圾收集信息

（2）持久代并发收集次数

（2）传统GC信息

（4）花在年轻代和年老代回收上的时间比例

减少年轻代和年老代花费的时间，一般会提高应用的效率

吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。

3、较小堆引起的碎片问题

因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：

-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。

-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩

八、class类文件的结构（TODO）

九、虚拟机类加载机制

类加载的时机

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个周期包括：加载、验证、准备、解析、初始化、使用、卸载7个阶段。验证、准备、解析3个部分统称为连接。

加载、验证、准备、初始化、卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段再开始，这是为了支持Java语言的运行时绑定（也称动态绑定或晚期绑定）。

（1）遇到new、getstatic、publicstatic、invokestatic这4条字节码指令时，如果类没有进行初始化，则需要触发其初始化。

生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译器吧结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。

（2）使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。

（3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发器父类的初始化。

（4）当虚拟机启动时，用户需要知道一个要执行的主类（包含main()方法的那个类），虚拟机会初始化这个主类。

（5）当使用JDK1.7的动态语言支持时、如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_puStatic、REF_invokeStatic的方法句柄、并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

这5种场景的行为称为对一个类进行主动引用。除此之外、所有引用类的方式都不会触发初始化，称为被动引用。

类加载的过程

1、加载

加载是类加载（Class Loading）过程的一个阶段。在加载阶段、虚拟机需要完成以下3件事情：

（1）通过一个类的全限定名来获取定义此类的二进制字节流。

（2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

（3）在内存中生成一个代表这个类的java.lang.Class 对象，作为方法区这个类的各种数据的访问入口

2、验证

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机的自身安全。

（1）文件格式验证

第一阶段要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。这一阶段可能包括下面这些验证点：

- - 是否以魔数0xCAFEBABE开头。
  - 主、次版本号是否在当前虚拟机处理范围之内。
  - 常量池的常量中是否有不被支持的常量类型（检查常量tag标志）。
  - 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。
  - CONSTANT_Utf8_info 型的常量中是否有不符合UTF8编码的数据。
  - Class文件中各个部分及文件本身是否有被删除的或附件的其他信息。
  - ...

该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个Java类型信息的要求。这阶段的验证是基于二进制字节流进行的，只有通过这个阶段的验证，字节流才会进入内存的方法区进行存储，所以后面的3个阶段全部基于方法区的存储结构进行的，不会再直接操作字节流。

（2）元数据验证

第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求，这个阶段可能包括的验证点如下。

- - 这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）。
  - 这个类的父类是否继承了不允许被继承的类（被final修饰的类）。
  - 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。
  - 类中的字段，方法是否与父类产生矛盾（例如覆盖了父类的final字段，或者出现不符合规则的方法重载，例如方法的参数都一致，但返回值类型却不同等）。

第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在不符合Java语言规范的元数据信息。

（3）字节码验证

第三阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。在地儿极端对元数据信息中的数据类型昨晚校验后，这个阶段将对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的时间，例如：

- - 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作。
  - 保证跳转指令不会跳转到方法体以外的字节码指令上。
  - 保证方法体重的类型转换是有效的。

（4）符号引用验证

最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验，通常需要校验下列内容：

- - 符号引用中通过字符串描述的全限定名是否能找到对应的类。
  - 在指定类中是否存在符号方法的字段描述符以及简单名称所描述的方法和字段。
  - 符号引用中的类、字段、方法的访问性（private、protected、public、default）是否可以被当前类访问。

3、准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这个阶段中两个容易混淆的概念，这个时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。

在通常情况下初始值是零值，如果类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量Value就会被初始化为ConstantValue属性所指定的值。

4、解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，符号引用在Class文件中它以CONSTANT_Class_info、CONSTANT_fieldref_info、CONSTANT_Methodref_info等类型的常量出现。

符号引用（Symbolic References）:符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位达到目标即可。符号引用与虚拟机实现的内存布局无关，引用目的目标并不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是他们能感受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。

直接引用（Direct References）：直接引用可以是直接指向目标的指针、相对偏移量或是一个间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在内存中存在。

类或接口解析

字段解析

类方法解析

接口方法解析

5、初始化

初始化阶段是执行类构造器<clinit>()方法的过程。

类加载器

虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。

1、类与类加载器

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机的唯一性，每一个类加载器，都拥有一个独立的类名称空间。比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类必定不相等。

2、双亲委派模型

从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器(Bootstrap ClassLoader),这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一种就是所有其他的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoder。

类加载器可以划分更细致一些，绝大部分都会使用到以下3中系统提供的类加载器。

启动类加载器（Bootstrap ClassLoader）:

这个类加载器负责将存放在JAVA_HOME\lib 目录中的，或者-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可。

扩展类加载器（Extension ClassLoader）:

这个类加载器由sun.misc.Launcher$ExtClassLoader实现，它负责JAVA_HOME\lib\ext目录中的，或者被java.exts.dirs系统比那里锁指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

应用程序类加载器（Application ClassLoader）:

这个类加载器由sun.misc.Launcher$AppClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所有一般也称它为系统类加载器。它负责加载用户路径（ClassPath）所指定的类库，开发者可以直接使用这个类加载器，如果应用程序没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

上图展示的类加载器之间的这种层次关系，称为类加载器的双亲委派模型（Parents Delegation Model）。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这个类加载器之间的父子关系一般不会以继承的关系来实现，而是都使用组合关系来复用父加载器的代码。

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载。

优点：Java类随着它的类加载器一起具备了一种带有优先级的层级关系。

双亲委派模型对于保证Java程序的稳定运作很重要，实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法中：先检查是否被加载过，若没有加载则调用父加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，爆出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

3、破坏双亲委派模型

十、Java内存模型与线程

Java内存模型

Java虚拟机规范中试图定义一种Java内存模型(Java Memory Model，JMM)来屏蔽掉各种硬件和操作系统的内存访问差异，以实现各种硬件和操作系统的内存访问差异。

主内存和工作内存

Java内存模型的主要目标是定义程序中的各个变量的访问规则，即在虚拟机中奖变量存储到内存和从内存中取出变量这样的底层细节。

Java内存模型规定了所有变量都存储在主内存中。每条线程还有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量所有操作（读取、赋值等）都必须在工作内存中进行，而不能读取主内存中的变量。不同的现场之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。

内存间交互操作

关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之间的实现细节,Java内存模型中定义以下8种操作来完成，虚拟机实现时必须保证下面提及的每一种操作都是原子的，不可再分的。(对于double、long类型的变量来说，load、store、read和write操作在某些平台上允许有例外)。

lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。

unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。

read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用。

load（载入）：作用于工作内存的变量，它把read操作从主内存得到的变量值放入工作内存的变量副本中。

use（使用）：作用于工作内存的变量，它把工作内存中的一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值字节码指令时将会执行这个操作。

assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。

store（存储）：作用于工作内存的变量，它把工作内存中的一个变量的值传送到主内存中，以便随后的write操作使用。

write（写入）：作用于主内存的变量，它把Store操作从主内存中得到的变量的值放入主内存的变量中。

对于volatile型变量的特殊规则

关键字volatile是Java虚拟机提供的最轻量级的同步机制，

当一个变量定义为volatile之后，它将保证此变量对所有线程的可见性，指当一个线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。而普通变量不能做到这一点，普通变量的值在线程间传递均需要通过主内存来完成。

volatile变量在各个线程的工作内存中不存在一致性问题，在各个线程的工作内存中，volatile变量也可以存在不一致的情况，但由于每次使用之前都先刷新，执行引擎看不到不一致的情况，因此可以认为不存在一致性问题，但是Java里面的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的。

由于volatile变量只能保证可见性，在不符合一下两条规则的运算场景中，仍要通过加锁(synchronized或java.util.concurrent)来保证原子性。

（1）运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。

（2）变量不需要与其他的状态变量共同参与不变约束。

使用volatile变量的第二个语义是禁止指令重排序优化，普通的变量仅仅会保证在该方法执行的过程中所有依赖赋值结果的地方都能获正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致，因为在一个线程的方法执行过程中无法感知到这点。这也就是Java内存模型中描述的所谓的‘线程内表现为串行的语义’。

public class Singleton{

private volatitle static Singlton instance;

public static Singleton getInstance(){

if(instance == null ){

synchronized(Singleton.class){

instance = new Singleton();

}

return instance;

}

有volatile修饰的变量，赋值后多执行了一个'lock addl $0X0,(%esp)',这个操作相当于一个内存屏障，指重排序时不能把后面的指令重排序到内存屏障的位置。

原子性、可见性与有序性

Java内存模型是围绕着在并发过程中如何处理原子性、可见性、有序性这三个特征来建立。

原子性（Atomicty）：

由Java内存模型来直接保证的原子性操作包括read、load、assign、use、store和write，大致可以认为基本数据类型的访问读写是具备原子性的（long和double的非原子性协定）。

如果应用场景需要一个更大范围的原子性保证，Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式地使用这两个操作，反应到Java代码中国就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。

可见性（Visibility）：

可见性是当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此，普通变量与volatile变量的区别是，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。

除了volatile之外，Java还有两个关键字能实现可见性，即syhchronized和final。同步块的可见性是由“对一个变量执行unlock操作之前，必须先把变量同步回主内存中（执行store、write）”这条规则获得的，而final关键字的可见性是指：被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把“this”的引用传递出去，那在其他线程中就能看见final字段的值。

有序性（Ordering）：

Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句是指“线程内表现为串行的语义”，后半句这是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。

Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一个时刻只允许一条线程对其进行lock操作”这条规则获得的，这条规则决定了持有同一个锁的两个同步快只能串行地进入。

先行发生原则

先行发生原则，它是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们可以通过几条规则一揽子解决并发环境下两个操作之间是否可能存在冲突的所有问题。

先行发生是Java内存模型中定义的两项操作之间的偏序关系，如果说操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被操作B观察到，"影响"包括修改了内存中共享变量发生的值、发送了消息、调用了方法等。

下面是Java内存模型下一些"天然的"先行发生关系，这些先行发生关系无须任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们随意地进行重排序。

程序次序规则：

在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确来说，应该是控制流顺序而不是程序代码顺序，因为要考虑分支，循环等结构。

管程锁定规则：

一个unlock操作先行发生于后面对同一个锁的lock操作，这里必须强调的同一个锁，而"后面"是指时间上的先后顺序。

volatile变量规则：

对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的"后面"同样是指时间上的先后顺序。

线程启动规则：

Thread对象的start()方法先行发生于次线程的每一个动作。

线程终止规则：

线程中所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行。

线程中断规则：

对线程方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测到是否有中断发生。

对象终结规则：

一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize()方法的开始。

传递性：

如果操作A先行发生于操作B，操作B先行发生于操作C那就可以得出操作A先行发生于操作C的结论。

Java与线程

线程的实现

Java线程调度

状态转换

Java语言定义了5种线程状态，在任意一个时间点，一个线程只能有且只有其中一种状态，这5种状态分别如下。

新建（New）:

创建后尚未启动的线程处于这种状态。

运行（Runable）:

Runable包括操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可能正在执行，也有可能正在等待着CPU为它分配执行时间。

无限期等待（Waiting）：

处于这种状态的线程不会被分配CPU执行之间。它们要等待被其他线程显式地唤醒。

以下方法会被线程陷入无限期的等待状态：

没有设置Timeout参数的Object.wait()方法。

没有设置Timeout参数的Thread.join()方法。

LockSupport.park()方法。

限期等待（Timed Waiting）：

处于这种状态的线程也不会被分配CPU执行时间，不过无须等待被其他线程显式地唤醒，在一定时间之后让它们会由系统自动唤醒。

以下方法会被线程陷入限期的等待状态：

Thread.sleep()方法。

设置了Timeout参数的Object.wait()方法。

设置了Timeout参数的Thread.join()方法。

LockSupport.parkNanos()方法。

LockSupport.parkUitls()方法。

阻塞（Blocked）：

线程被阻塞了，“阻塞状态” 与等待状态的区别是：“阻塞状态”在等待着获取一个排他锁，这个时间将在另外一个线程放弃这个锁的时候发生：而“等待状态”则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态。

结束（Terminated）：已终止线程的线程状态，线程已经结束执行。

十一、线程安全与锁优化

线程安全

当多个线程访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用该方法进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那这个对象是线程安全的。

Java语言中的线程安全

Java语言中各种操作共享的数据分为以下5类：不可变，绝对线程安全，相对线程安全、线程兼容和线程对立。

不可变

不可变的对象一定是线程安全的。只要一个不可变的对象呗正确的构建出来（没有发生this引用逃逸的情况），那其外部的课件状态永远也不会改变，永远也不会看到它在多个线程之中处于不一致的状态。“

如果共享数据是一个基本数据类型，那么只要在定义时使用final关键字修饰它就可以保证它是不可变的。如果共享数据是一个对象，那就需要保证对象的行为不会对其状态产生任何影响才行。

保证对象行为不影响自己状态的途径有很多种，其中最简单的就是把对象中带有状态的变量都声明为final，这样在构造函数结束之后，它就是不可变的。

绝对线程安全

绝对的线程安全完全满足Brian Goetz给出的线程安全的定义，这个定义其实是很严格的，一个类要达到“不管运行时环境如何，调用者都不需要任何额外的同步措施”通常需要付出很大的，甚至有时候是不切实际的代价。在Java API中标注自己是线程安全的类，大多数都不是绝对的线程安全。

相对线程安全

相对线程安全就是我们通常意义上所讲的线程安全，它需要保证对这个对象单独的操作是线程安全的。我们在调用的时候不需要做额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。

线程兼容

线程兼容是指对象本身不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用，我们平常说一个类不是线程安全的，绝大多数时候指的是这一种情况。Java API中大部分的类都是属于线程兼容的，如遇前面的Vector和HashTable相对应的集合类ArrayList和HashMap等。

线程对立

线程对立是指无论调用端是否采取了同步措施，都无法在多线程环境中并发使用的代码。由于Java语言天生就具备多线程特性，线程对立这种排斥多线程的代码是很少出现的而且通常都是有害的，应当尽量避免。

线程安全的实现方法

同步互斥

同步互斥是常见的一种并发正确性保障手段。同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一个（或者是一些，使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区、互斥区和信号量都是主要的互斥实现方式。因此，在这4个字里面，互斥是因，同步是果：互斥是方法，同步是目的。

在Java中，最基本的互斥同步字段就是synchronized关键字，synchronized关键字经过编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。如果Java程序中的synchronized明确指定了对象参数，那就是这个对象的reference：如果没有明确指定，那就根据syhchronized修饰的是实例方法还是类方法，去取对应的对象实例或Class对象来作为锁对象。

根据虚拟机规范的要求，在执行monitorenter指令时，首先要尝试获取对象的锁。如果这个对象没被锁定，或者当前线程已经拥有了哪个对象的锁，把锁的计数器加1，相应的在执行monitorexit指令时会将锁计数器减1，当计数器为0时，锁就被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到对象锁被另外一个线程释放为止。

在虚拟机规范对monitorenter和monitorexit的行为描述中，有两点是需要特别在注意的。首先，synchronized同步块在同一条线程来说是可重入的，不会出现自己把自己锁死的问题。其次，同步快在已进入的线程执行完之前，会阻塞后面其他线程的进入。

除了synchronized之外，我们还可以使用java.util.concurrent包中的重入锁（ReentrantLock）来实现同步，在基本用法上，ReentrantLock与synchronized很相似，他们都具备一样的线程重入特性，只是代码写法上有点区别，一个表现为API层面的互斥锁，另一个表现为元素语法层面的互斥锁。不过，想比synchronized,ReentrantLock增加了一些高级功能。主要有以下3项：等待可中断，可实现公平锁，以及锁可以绑定多个条件。

等待可中断是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情，可中断特性对处理执行时间非常长的同步块很有帮助。

公平锁是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平锁则不保证这点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized中的锁时非公平的，ReentrantLock默认情况下也是非公平的，但可以通过带布尔值的构造函数要求使用公平锁。

锁绑定多个条件是指一个ReetrantLock对象可以同时绑定多个Condition对象，而在synchronized中，锁对象的wait()和notify()或notifyAll()方法可以实现一个隐含的条件，如果要和多余一个的条件关联的时候，就不得不额外地添加一个锁，而ReetrantLock则无须这样做，只需要多次调用newCondition()即可。

非阻塞同步

互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也成为阻塞同步。从处理问题的方式来说，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施(例如加锁)，那就肯定会出现问题，无论共享数据是否真的会出现竞争，它都要加锁、用户态核心态转换，维护锁计数器和检查室友有被阻塞的线程需要唤醒等操作。随着指令集的发展，我们有了另外一个选择：给予冲突检测的乐观并发策略，就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生了冲突，那就再采取其他的补偿措施（最常见的补偿措施就是不断的重试，直到成功为止），这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步操作称为非阻塞同步。

硬件保证一个语义上看起来需要多次操作的行为只通过一条处理器指令就能完成，这类指令常用的有：

测试并设置（Test and Set）

获取并增加(Fetch and Increment)

交换(Swap)

比较并交换(Compare and Swap CAS)

加载链接/条件存储(Load Linked/Store Conditional LL/SC)

CAS指令需要有3个操作数，分别是内存位置（在Java中可以简单理解为变量的内存地址，用V表示）、旧的预期值（用A表示）和新值（用B表示）。CAS指令执行时，当且仅当V符号旧预期值符合旧预期值A时，处理器用新值B更新V的值，否则它就不执行更新，但是无论是否更新了V的值，都会返回V的旧值，上述的处理过程是一个原子操作。

在JDK1.5之后，Java程序中才可以使用CAS操作，该操作是由sun.misc.Unsafe类里面的compareAndSwapInt()和compareAndSwapLong()等几个方法包装提供，虚拟机在内部对这些方法做了特殊处理，即时编译出来的结果就是一条平台相关的处理器CAS指令，没有方法调用的过程，或者可以认为是无条件内联进去了。

由于Unsafe类不是提供给用户程序条用的类（Unsafe.getUnsafe()代码中只有启动类加载器（BootStrap ClassLoader）加载的Class才能访问它），因此，如果不采用反射手段，我们只能通过其他的API来间接使用它，如J.U.C包里面的整数原子类，其中的compareAndSet()和getAddIncrement()等方法都使用了Unsafe类的CAS操作。

CAS操作的缺点：无法涵盖互斥同步的所有使用场景，并且CAS从语义上来说并不是完美的，存在这样的一个逻辑漏洞：如果一个变量V初次读取的时候是A值，如果在这段期间它的值曾经被改成了B，后来又被改回了A，那CAS操作就会误认为它从来咩有改变过。这个漏洞称为CAS操作“ABA”问题。J.U.C包为了解决这个问题，提供了一个带有标记的原子引用类“AtomicStampedReference”，他可以通过控制变量的值的版本来保证CAS的正确性。不过目前来说这个类比较鸡肋，大部分情况下ABA问题不会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步可能会比原子类更高效。

无同步方案

要保证线程安全，并不是一定要进行同步。同步只是保证共享数据争用事的正确性手段，如果一个方法本来就不涉及共享数据，那它自然就不许任何同步措施来保证正确性，因此会有一些代码天生就是线程安全的。

可重入代码：这种代码也叫做纯代码，可以在代码执行的任何时刻中断它，转而去执行另外一段代码，包括递归调用它本身，而在控制权返回后，原来的程序不会出现任何错误。相对线程安全来说，可重入性是更基本的特性，它可以保证线程安全，即所有的可重入的代码都是线程安全的，但是并非所有的线程安全的代码都是可以重入的。

线程本地存储：把共享数据的可见范围限制在同一个线程之内，无须同步也能保证线程之间不出现数据争用的问题。例如生产者-消费者模型。

锁优化

适应性自旋、锁清除、锁粗化、轻量级锁和偏向锁、这些锁优化技术都是为了在线程之间更高效地共享数据，以及解决竞争问题，从而提高程序的执行效率。

自旋锁与自适应自旋

互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性能带来了很大的压力。共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得，如果物理机器有一个以上的处理器，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程“稍等一下，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只需让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁（JDK1.4.2引入，JDK1.6默认开启）。

自旋等待不能代替阻塞，自身虽然避免了线程切换的开销，但它是要占用处理器时间的，在被占用的时间很短的情况下，自旋等待的效果就会比较好，反之，如果锁被占用的时间很长，自旋的线程会消耗处理器资源，带来性能上的浪费。因此，自旋等待时间必须要有一定的限度，如果自旋超过了限定的次数任然没有成功获得锁，就应当使用传统的方式去挂起线程了。自旋次数的默认值是10次，用户可以使用参数-XX:PreBlockSpin来更改。

在JDK1.6中引入了自适应的自旋锁。自旋的时间不在固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定，以避免浪费处理器资源。

锁清除

锁清除是指虚拟机及时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行清除。锁清除的主要判定依据来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。

锁粗化

为了使得需要同步的操作数量尽量减少，可以将同步快的作用范围限制的尽量小，只在共享数据的实际作用域中才进行同步，如果存在锁竞争，那等待锁的线程也能尽快拿到锁，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁的进行互斥同步操作也会导致不必要的性能损耗。针对这类情况，如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁的范围扩展（粗化）到整个操作序列的外部。

轻量级锁

轻量级锁是JDK1.6之中加入的新型锁机制，在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

轻量级锁能提升程序同步性能的依据是“对于绝大部分的锁，在整个同步同期都不是不存在竞争的”。如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁会比传统的重量级锁更慢。

偏向锁

偏向锁是JDK1.6中引入的一项锁优化，它的目的是消除数据在无竞争情况下的同步原语。轻量级锁在无竞争的情况下使用CAS操作去清除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都清除掉，连CAS操作都不做。

偏向锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。

Angel_Heart_Java

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
JVM 读书笔记

一、JVM运行时数据区程序计数器Java虚拟机栈本地方法栈Java堆方法区运行时常量池二、对象是否存活分析引用计数法可达性分析算法三、垃圾收集算法标记-清除算法复制算法标记-整理算法分代收集算法四、垃圾回收器Serial收集器ParNew收集器Parallel Scavenge（并行回收）收集器Serial Old 收集器...
复制链接

扫一扫

专栏目录