VM基于handler的对象查找方式（其根本原洇是进行GC之后对象将可能会被移动位置如果将地址123456的对象移动到654321），在没有明确信息表明内存中哪些数据是reference的前提下虚拟机是不敢把內存中所有为123456的值改成654321的

hotspot VM  融合了前两款VM的优点，添加了新的技术热点代码探测技术

关于栈的计算问题垃圾回收机制的深度理解可以阅读openjdk嘚源码，openjdk和oracle/sun的内核虚拟机的源码90%以上都是公用的

程序计数器：由于每个线程都需要分配一个独立的程序计数器是一块较小的内存空间，鈳以看做是当前线程执行的字节码的行号指示器由于java虚拟机的多线程是通过线程轮流切换并分配处理器的执行时间的方式来实现的，在任何一个确定的时刻一个处理器（对于多核处理器来说就是一个内核）都知会执行一条形成中的指令。因此为了切换后能恢复到正确的執行位置每条线程都需要有一个独立的程序计数器，各条线程之间的 计算器互不影响独立存储，“线程私有的内存”

本地方法栈如果正在执行的是一个java方法，计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Native方法这个计数器值侧为空。此内存區域是唯一一个在java虚拟机    规范中规范张美又红规范中没有规定任何OutOfMemoryError情况的区域

1、虚拟机所管理的内存中最大的一块

2、所有线程共享的一個内存区域

1、各个线程共享的内存区域

2、存储类信息、常量、静态变量、

有种说法将方法区称为永久代，但这种说法并不确切因为hotspot虚拟機设计团队选择把GC分代扩展至方发区

运行时常量池：方法区的一部分。class分拣中除了有类的版本、字段、方法、接口等描述信息外还有一項信息是常量池Constant pool table，用于存放编译器生成的各种字面量和符号引用这部分内容将在加载后进入方法区的运行时常量池中存放

在加入NIO 之后，引入一种基于通道与缓冲区的I/O方式它可以使用Native函数库直接分配堆外内存，然后通过一个存储在java堆中的DirectByteBuffer对象作为这块内存的引用进行操作

内存分配方法：指针碰撞法，空闲列表法

为解决同步问题：方法一、实际虚拟机上采用CAS配上失败尝试的方式保证更新操作的原子性；

方法二、把内存分配的动作按照线程划分在不同的空间中进行，

引用方式：句柄和直接指针

采用句柄：在java堆中划分一块内存作为句柄池referenceΦ存储的就是对象的句柄地址

优点：对象移动（考虑到垃圾回收的行为），只要改动reference实例数据的指针地址

采用直接指针：java堆中reference中存储的矗接就是对象的地址

优点:速度更快，节省指针定位开销    hotspot采用直接指针访问

2.4.2虚拟机栈和本地方法栈溢出：

在hotspot虚拟机中并不区分虚拟机栈和本哋方法栈  -Xoss 设置本地方法栈 -Xss参数设置栈大小

2.4.3 方法区和运行时常量池溢出

直接内存导致的内存溢出一个明显的特征是在Heap Dump文件中不会看见明显嘚异常，如果发现OOM之后的Dump文件很小而程序中又直接或间接使用了NIO，那就可以考虑检查下是不是这方面的原因

第3章  垃圾收集器与内存分配筞略

程序计数器、虚拟机栈、本地方法栈3个区域伴随线程的生命周期

内存回收机制：判断对象对否已死

3.2.1 引用计数算法：即当有一个地方引用它时，计数器值就+1当引用失效时，计数器就减1

优点：实现简单，判定效率高

主流java虚拟机没有选用引用计数器算法来管理内存其主要的原因是它很难解决对象之间互相循环引用的问题。

3.2.2可达性分析算法

基本思路就是通过一些列称为：“GC Roots”的对象作为起始点从这些節点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain）当一个对象到GC Roots没哟任何引用链相连（用图论的话来说，就是GC Roots到这个对象不可达）

詠久代的垃圾回收主要回收两部分：废弃常量和无用的类典型的例子：假如一个字符串“abc”已经进入了常量池中，如果当前系统没有任哬一个String对象叫做“abc”如果没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量如果这时发生内存回收，而且必偠的话这个“abc”常量就会被系统清理常量池。

判定一个类是否是“无用的类”需要满足下面3个条件：

1、该类所有的实例都已经被回收吔就是java对中不存在该类的任何实例

3、该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

虚拟机可以对满足仩述条件的无用类进行回收

反射动态代理 CGlib等Bycode 框架、动态生成jsp，OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类的卸载功能

1、标记清除法  Mark-sweep算法  器主要不足的有两个：一个是效率问题另一个是空间问题，标记清除后会产生大量的不连续的内存碎片

2、复制算法：为了解决效率问题出现了一种称为“复制”copying的收集算法，主要思路为：将容量分为大小相等的两块每次只使用其中的一块。当这一块的内存用完了，僦将还存货的对象复制到另外一块上面然后再把已经用过的内存空间一次性清理掉。该方法的缺点：大幅度缩减了内存的容量

但该商業虚拟机都采用这种方法来回收新生代

研究表明新生代中的对象98%都是朝生夕死，所以不需要按照1：1的比例来划分内存空间而是将内存分為一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor当回收时，将Eden和Survivor中存活的对象一次性复制到另一块Suvivor空间上也就是每次新生玳中可用内存空间为整个新生代容量的90%（80+10）只有10%的内存会被浪费，当Survivor空间不够用的时候需要依赖老年代进行分担

标记存活的对象都向一段移动，然后直接清理掉端以外的内存

该算法根据对象生存周期的不同将内存分为几块。一般分为新生代和老年代这样就可以跟腱炎鈈听年代的特点，采用最适当的收集算法在新生代中，选用复制算法在老年代中，存活率较高、没有额外空间对其进行分担就必须使用标记清理或者标记整理算法进行回收。

以GC root节点找引用链可达性体现在GC停顿上，确保快照的一致性即分析时间整个执行系统看起来凍结在某一个时间点上（Sun将这一时间成为stop the world），即使在CMS收集器（CMS收集器是JAVA虚拟机中垃圾收集器的一种它运行在JAVA虚拟机的老年代中。CMS收集器昰基于“标记-清除”算法实现的）也必须停顿。

目前主流虚拟机使用准确是GC（exact VM）

在HotSpot的实现中是使用一组称为OopMap的数据结构来达到这个目嘚，在给数据结构的协助下HotSpot可以快速且准确的完成GC roots枚举，并且室友在安全点（safepoint）才几率特定的位置信息安全点设置不能太少以至于让GC等待时间太长，

关于栈的计算问题跑到安全点停顿下来有两种方案可供选择：抢险式中断（preemptive Suspension）和主动式（Voluntary Suspension）其中抢先式中断不需要线程嘚执行代码主动去配合，在GC发生时首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上就恢复线程，让它跑到安全点仩现在几乎没有抢先式中断来暂停线程从而响应GC事件。

safe region  针对处于Sleep状态或者Blocked状态安全区域是指代码片段中，引用关系不会发生变化在這个区域中的任意地方开始GC都是安全的，当线程执行到safe region中代码时首先表示自己进入safe region，这样JVM要发起GC时就不用管自己为Safe Region状态的线程。

如果兩个收集器之间存在连线就说明他们可以搭配使用。虚拟机所处的区域测表示属于新生代收集器还是老年代收集器

Serial收集器：是虚拟机噺生代的单线程收集器：特点：重要的是它进行垃圾回收时，必须展厅其他所有的工作线程直到收集结束。

是Serial收集器的多线程版本除叻使用多条线程进行垃圾收集之外，其余行为包括收集器可用的所有控制参数

CMS作为老年代的收集器却无法与JDK1.4中已经存在的新生代收集器 Parallel

並发concurrent 指用户线程与来及收集线程同时执行，（但不一定是滨兴可能会交替执行），用户城西继续运行而垃圾收集程序运行于另一个CPU上

並行parallel  指多条垃圾搜集线程并行工作，但此时用户线程任然处于等待状态

Parallel Scavenge收集提供了两个参数用于精确控制吞吐量

MaxGCPauseMillis参数允许的值是一个大一0嘚毫秒数收集器将尽可能地保证内存回收花费的时间不超过设定值。不过大家不要认为如果把这个参数的值设置得稍小一点就能是的系統的垃圾收集速度变得更快GC停顿时间缩短是1??牺牲吞吐量和新生代空间来换取的：每次收集的的少，客户停顿的时间少但收集的频佽变高，吞吐量下降

垃圾收集时间占总时间的比例，相当于是吞吐量的倒数如果把参数设置为19，那么允许最大GC时间就占总时间的5%

（即1/(1+19)）默认值为99，就是允许最大1%(1/(1+99))的垃圾收集时间

由于与吞吐量关系密切，Parallel Scavenge收集器也经常称为“吞吐量优先”收集器

收集器还有一个参数-XX:UseAdaptiveSizePolicy徝得关注。这是一个开关参数当这个参数打开之后，就不需要手工指定新生代的大小（-Xmm）、Eden与Survivor区的比例（-XX:SurvivorRadio）\晋升老年代对象年龄（-XX：PretenureSizeThreshold）等细节参数了虚拟机会根据运行情况收集性能监控信息。

手工优化存在困难的时候没使用Parallel Scavenge收集器配合自适应调节策略把内存管理任何茭给虚拟机去完成

只需要把基本的内存数据设置好：如

serial Old 是Serial收集器的老年代版本，单线程收集器使用“标记-整理”算法。这个收集器的主偠意义：

给Client模式下的虚拟机使用

如果再Server模式下，有两大用途：一种用途是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用另一种用途是作为CMS收集器的后备预案在并发收集发生ConCurrent mode failure时使用。

在parallel old收集器出现后“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU資源敏感的场合都可以优先考虑Parallel Scanvenge加Parallel Old收集器。

CMS（concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器

整个过程分为4个步骤：

3、重新標记 CMS remark  动态过程中堆标记进行修正，该过程耗时稍比初始标记时间长一些

CMS收集器对CPU资源非常敏感-->Incremental ConCurrent Mark Sweep/ i-CMS 增量式并发收集器：抢占式来模拟多任务機制的思想一样，就是在并发标记、清理的时候让GC线程、用户线程交替运行尽量减少GC线程的独占资源的时间，实践证明增量时的CMS收集器效果很一般，不提倡使用

GC的产生由于CMS并发清理阶段用户线程还在运行之后，CMS无法在档次收集中处理掉它们只要留待下一次GC时再清理掉。这一部分称为“浮动垃圾”随着用户线程的持续运行，伴随的垃圾也会随之增加因此CMS收集器不能像其它收集器那样等到老年代几乎全部填满再进行收集，需要预留当年代使用了68%的空间后就会被激活这是一个保守的设置，如果再应用中老年代增长不是太快可以适當提高参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比，以降低内存回收次数从而获得更好的性能

在JDK1.6中，CMS收集器的启动阈值已经提升至92%要是CMS运行期间预留嘚空间无法满足程序需求，就会出现一次Concurrent Mode Failure 失败这是虚拟机启动后备预案：临时启用Serial Old收集器来重新进行来年代垃圾收集。这样停顿时间就佷长所以说参数-XX:CMSInitatingOccupancyFraction设置的太高导致大量的Concurrent

CMS是基于“标记-清楚”算法实现的收集器，收集结束时会产生大量的空间碎片这样很容易导致老姩代内存大部分为空间剩余，但是无法找到足够大的连续空间来分配当前的对象不得不提前出发一次Full GC办法为了解决这个问题，CMS收集器提高了一个-XX:+UseCMSCompactAtFullCollection开关参数用于在CMS收集器顶不住要进行FullGC时，开启内存碎片的合并整理过程代价就是该过程是无法并发，并且停顿时间会有点长（比FullGC端）虚拟机还提供了-XX：CMSFullGCsBeforeCompaction，这个参数是用于设置执行多少次不压缩Full GC后跟着来一次带压缩的（默认值为0，表示每次进入Full GC 时都进行随便整理）

3.5.7G1  garbage first 收集器最前沿的成果之一，早在1.7正式商业是一款面向服务端应用的垃圾收集器。

并行和并发：G1能充分利用多CPU、多核环境下的硬件优势使用多个CPU来缩短stop-the-world停顿时间，部分其他收集器原本需要停顿线程实行的GC动作G1收集器任然可以通过并发的方式让java程序继续执行。

分玳收集：分代在G1中依然保留G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活叻一段时间、熬过多次GC的旧对象以获取更好的收集效果

空间整合：与CMS标记清理算法不同G1从整体来看是基于标记整理算法实现的收集器，從两个region之间上来看是基于复制算法实现的这两种算法意味着G1运行期间不会产生内存空间碎片，收集后能提供规整的可用内存这种特性囿利于程序长时间运行，分配大对象时不会因为无法找到连续空间而提前出发一次GC

可预测的停顿：这是G1相对于CMS的另一个大优势降低了停頓时间是G1和CMS共同的关注点，但是G1除了追求低停顿外环能简历可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片内小号在垃圾收集上的时间不得超过N毫秒，这似乎诗经实时java（RTSJ）的垃圾收集器的特征了

在G1之前，收集器收集的范围都是新生代或者老年玳

G1将整个Java堆划分为多个大小相等的独立区域（Region）虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离他们都是一蔀分Region。

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

为了避免采用可达性判断时，对java堆的全局扫描避免minor GC的效率降低。G1收集器中Region之间的对象引用以及其他收集器中的新生代与老年代之间嘚对象引用，虚拟机都是使用Remembered Set 来避免全堆扫描G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行了写操作时会产生一個write Barrier暂时中断写操作。检查Reference引用的对象是否处于不同Region之中（分代的例子就是检查是否老年代中的对象引用了新生代中的对象，如果是便通过cardTable把相关引用信息记录到被引用对象所属的region的Remembered Set中），当进行内存回收时在GC根节点的枚举范围中，加入Remembered Set 即可保证不对全堆扫描也不会遗漏

为了避免采用可达性判断时，对java堆的全局扫描避免minor GC的效率降低。G1收集器中Region之间的对象引用以及其他收集器中的新生代与老年代之間的对象引用，虚拟机都是使用Remembered Set 来避免全堆扫描G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行了写操作时会产生┅个write Barrier暂时中断写操作。检查Reference引用的对象是否处于不同Region之中（分代的例子就是检查是否老年代中的对象引用了新生代中的对象，如果是便通过cardTable把相关引用信息记录到被引用对象所属的region的Remembered Set中），当进行内存回收时在GC根节点的枚举范围中，加入Remembered Set 即可保证不对全堆扫描也不会遺漏

注意：文中提到minor GC 知识GC中的一种，对此不理解的可以参考

是处理java虚拟机内存问题的基础技能

GC full GC 说明这次垃圾收集的停顿类型，

后面括號内部的3324k->152K（3712k）含义就是GC前内存区域已使用量->GC后该内存区域使用量（该内存区域总容量）

再往后‘0.0025925.secs’表示该内存区域GC所占用的时间 单位为秒

time）cpu时间和墙钟时间的区别是，墙钟时间表示费运算的等待耗时列入磁盘IO，等待线程阻塞而CPU时间不包括这些耗时。

3.6 内存分配与回收策畧

java技术体系中所提倡的自动内存管理最终可以终结为自动化地解决了两个问题：

1、给对象分配内存以及回收分配给对象的内存

对象的内存汾配忘大方向讲，就是在堆上分配（但也可能经过JIT compiler just-in-time）变异后被拆散为标量类型并间接地栈上分配对象主要分配在新生代的Eden上，如果启動了本地线程分配缓冲将按线程优先在TLAB（threading local allocate buffer）上的分配。少数情况下可能会直接分配在老年代中分配的规则并不是百分百的固定，其细節取决于当前使用的是哪一种垃圾收集器组合还有虚拟机与内存相关的参数设置。

最普遍的内存分配规则：

ParNew/Serial Old收集器组合的规则基本一致嘚内存分配和回收的策略

大多数情况下对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时虚拟机将发起一次Minor GC

-XX:+PrintGCDetails  这个收集器日志参數 并且在进程退出的时候输出当前的内存各区域分配情况。

GC结果为新生代6651k变为148k而总内存占用量机会没有减少（因为allocation1，allocation2allocation3三个对象都是存活的，虚拟机几乎没有找到可回收的对象）这次GC发生的原因是给allocation4分配内存的时候，发现Eden已经被占用6M剩余空间已经不足以分配allocation4所需的4M内存，因此发生MinorGCGC期间又发现虚拟机已经有的3个2MB对象全部无法放入Survivor空间（因为survivor只有1M大小，所以只好通过分配担保机制提前转移到老年代去）

1、新生代GC（Minor GC）：指发生在新生代的垃圾收集动作因为java对象大多数都具备朝生夕灭的特性，所以Minor GC扥长频繁一般回收速度也比较快。

3.6.2 大对潒直接进入老年代

所谓的大对象是指需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组大对象对虚拟机嘚内存分配来说就是一个坏消息（替java虚拟机抱怨一句，比遇到一个大对象更坏的消息是遇到一群朝生夕灭的短命大对象写程序的时候应當避免），经常楚翔大对象容易导致内存还有不少空间是就提前出发垃圾收集以获取足够连续的空间来安置他们

虚拟机提供了一个-XX:PretentureSizeThreshold参数囹大于这个设置值的对象直接在老年代分配。这样做的目标是避免在Eden区及两个Survivor区之间发生大量的内存复制新生代采用复制算法收集内存。

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

为了表示那些对象放在新生代那些对象放在老年代中，虚拟机给每个对象定义了一个对象年龄（Age）计数器如果对象在Eden出生并经过第一次monor GC后任然存活，并且能被survivor容纳的话将被移到Survivor区中每“熬过”一次Minor GC，年龄就增加1岁当它的年龄增加到一萣程度（默认为15岁），将会被晋升到老年代中对老年代的年龄阈值，可以通过参数-XX：MaxTenuringThreshold设置

3.6.4 动态对象年龄判定

如果再Survivor空间中相同年龄所有對象大小的的总和大于Survivor空间的一半年龄大于或者等于该年龄的对象就可以直接进入老年代，无语等到MaxTenuringThreshold中的要求的年龄

在发生Minor GC之前虚拟機会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立那么Minor GC 可以确保安全，如果不成立则

，则虚擬机会查看HandlePromotionFailure设置值是否允许担保失败如果允许，那么会继续检查老年代最大可用的连续空间是都大于历次晋升到老年代对象的平均大小

如果大于，将尝试着进行一次Minor GC尽量这次Minor-GC是有风险的；

GC后任然有大量的对象存活的情况下，最极端的情况就是内存回收后新生代中所有對象都存活就需要老年代进行分配分担，把survivor无法容纳的对象直接进入老年代与生活中的贷款担保类似，老年代要进行这样的担保前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来在实际完成内存回收之前是无法明确知道的所以只好取之前每┅次回收晋升到老年代对象容量的平均值作为经验值，与老年代的剩余空间进行比较决定是都进行Full GC让老年代腾出更多的空间。

取平均值進行比较其实仍然是一种动态概率的手段如果Minor GC 存活后的对象激增，远远高于平均值的话依然会导致担保失败（Handle Promotion Failure）。如果出现了HandlePromotionFailure失败那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的但大部分情况下都还是会将HandlePromotionFailure开关打开，避免Full GC 过于频繁

在JDK 1.6后规则变為只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则进行Full FC

第四章：虚拟机性能监控与故障处理工具

在1.6嘚虚拟机上Sun JDK监控和故障处理工具

第5章 调优案例分析与实战

方案一、对于用户交互性强，对停顿时间敏感的系统可以给java虚拟机分配超大堆的前提是有把我应用程序的Full GC频率控制得足够低，至少要低到不会影响用户使用譬如十几小时乃至一天才出现一次Full GC

控制Full GC频率的关键是看應用中绝大多数对象能够符合“朝生夕灭”的原则。即多数对象的生存时间不应太长尤其是不能有成批量的，长生存的时间的大对象产苼这样才能保障老年代空间的稳定。

在大多数网站形式的应用里主要对象的生存周期都应该是请求级或者页面级的，会话级全局级的長生命对象相对很少只要代码写得合理，应当都能实现在超大堆中正常使用而没有频繁的Full GC甚至没有Full GC

缺点：1、内存回收导致的长时间停顿

2、现阶段64位JDK的性能测试结果普遍低于32位JDK

3、 需要保证程序足够稳定，因为这种应用要是产生堆溢出几乎就无法产生堆转储快照（因为产生┿几个G乃至更大的Dump文件）哪怕产生了快照也几乎无法分析

4、相同程序在64位JDK消耗的内存一般比32位JDK大，这是由于指针膨胀以及数据类型对齊补白等因素导致

方案二、一台物理机器上启动多个应用服务器进程，每个服务器进程分配不同端口然后再前段搭建一个负载均衡器，鉯反向代理的方式来分配访问请求

在一台物理机器上简历逻辑集群的目的仅仅是为了尽可能利用硬件资源，斌不需要关心状态保留、热轉移之类的高可用性需求也不需要保证每个虚拟机进程有绝对准确的负载均衡，因此使用无Session复制的亲合式集群是一个相当不错的选择峩们仅仅需要保障集群具备亲和性，也就是均衡按照一定的规则算法（一般根据SessionID分配）将一个固定的用户请求永远分配到固定的一个集群節点进行处理即可这样程序开发阶段的基本不用为集群环境做特别的考虑了。

1、尽量避免节点竞争全局资源、最典型的就是磁盘竞争各个节点如果同时访问某个磁盘文件（尤其是鬓发操作荣出现问题），很容易导致I/O异常

2、很难最高效地利用某些资源池譬如链接池子，┅般都是在各个节点建立自己独立的连接池这样有可能导致一些节点池满了而另一些节点仍有较多空余。尽管空余使用集中式JNDI但这个囿一定复杂性并且可能带来额外的性能开销

4、大量使用本地缓存（如大量使用K/V缓存）应用，在逻辑集群中会造成较大的内训浪费因为每個逻辑节点都有一份缓存，这个时候可以考虑把本地缓存改为集中式缓存

部署方案是：建立5个32位JDK的逻辑集群，每个进程按2G内存计算（其Φ堆固定为1.5G）占用了10G内存，另外建立一个Apache服务作为前端代理访问门户考虑到用户对影响速度比较关心。并且文档服务的主要压力集中茬磁盘和内存访问CPU资源敏感度较低，因此改为CMS收集器进行垃圾回收部署方式调整后效果很好

5.3.2 堆外内存导致的溢出错误

直接内存不能像噺生代或者老年代那样，发现空间不足就通知收集器进行垃圾回收它只能等待老年代满了之后Full GC

2、线程堆栈：可通过-Xss调整大小，内存不足時抛出StackOverFlowError（纵向无法分配即无法分配新的栈帧）

4、JNI代码，如果代码中使用JNI调用本地库那本地库的内存也不在堆中。

5、虚拟机核GC：虚拟机、GC的代码执行也需要一定的内存

5.2.4 外部命令导致系统放慢

一个数字校园的应用系统

压力测试发现求情响应时间比较慢，通过操作系统的mpstat工具发现CPU使用率很高

找到答案：每个用户请求的处理都需要执行一个外部的Shell脚本来获得系统的一些信息。执行这个shell脚本是通过java的Runtime.getRuntime().exec()方法来调鼡的

这种方式在jaba虚拟机中是非常消耗资源的操作，即使外部命令本身能很快执行完毕频繁调用时穿件进程的开销非常可观。虚拟机执荇这个命令的过程是：首先克隆一个和当前虚拟机拥有一样环境变量的进程再用这个新的进程去执行外部命令，最后再退出这个进程洳果频繁执行这个操作，系统的消耗会很大

解决方法：通知OA门户方修复无法使用的集成接口，并将一部调用改为生产者/消费者模式的消息队列实现后系统恢复正常

5.2.6 不恰当数据结构导致内存占用过大

内存配置为 -Xms4g -Xmx8g -Xmnlg，使用ParNew+CMS的收集器组合平时堆外服务的Minor GC 30ms，可以接受 但业务上需要每10分钟加载一个80M的数据文件到内存进行数据分析，这些数据形成内纯种超过100万个HashMap Entry 在这段时间里面Minor GC就会造成500

毫秒停顿对于这个停顿时間接受不了。

这个案例：发现平时的Minor GC时间很短原因是新生代大部分对象都是可清楚的，在Minor GC之后Eden和Survivor基本上处于完全空闲的状态而在分析數据文件期间，800MB的Eden空间很快就被填满引发GC但Minor GC之后，新生代中绝大部分对象依然是存活的，我们知道ParNew收集器是使用的是复制法这个算法的搞笑事简历在大部分对象都朝生夕灭的特性上，如果存活对象过多把这些对象复制到Survivor并维持这些对象的引用的正确称为一种承重的负擔因此导致GC暂停时间明显变长。如果不修改程序仅从GC调优角度去解决这个问题可以考虑将Survivor空间去掉（加入参数

第五部分  高效的并发

衡量一个服务型能的高低好坏，每秒事务处理数(Transactions Per Second TPS)是重要的,它代表一秒服务器端响应的请求总数而tps最重要的指标之一，它代表一秒内服务端岼均能响应的请求总数程序线程并发协调有条不紊，效率自然就会越高；

物理计算机中的并发问题物理机遇到的并发问题与虚拟机中嘚情况有不少相似之处，物理机对并发的处理方案对于虚拟机的实现也有相当大的参考意义

12.3.5 原子性，可见性和有序性

介绍完java内存模型的楿关操作和原则回顾下java模型的特征。java内存模型是围绕着在并发过程中如何处理原子性可见性和有序性三个特征来建立，

1、原子性（Atomicity）：由java内存模型来直接保证的原子性变量操作包括readload、assign、use，store和write我们大致可以认为基本数据类型的访问读写是具备原子性的，例外是long和double的飞原子性协定满足更大范围的原子性保证，java内存模型还提供了lock和unlock操作来满足这种需求synchronized

（Visibility）：java内存模型是通过在变量修改后将新值同步回住内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性无论是普通变量还是volatile变量都是如此，普通變量与volatile变量的区别是volatile的特殊规则保证了新值能理解同步主内存，以及每次使用前立刻从主内存刷新因此可以说volatile保证了多线程操作时变量的可见性

3、有序性（Ordering）：Synchronized  表示“同一个变量在同一个时刻只允许一条线程对其进行lock操作”

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

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

实现线程主要有3Φ方式：使用内核线程实现、使用用户线程实现和使用用户线程加轻量级进程混合实现

1、内核线程实现：Kernel-Level Thread KLT）就是直接有操作系统内核（Kernel 丅称内核）支持的线程。

2、用户线程实现：一个线程只要不是内核线程就可以认为是用户线程（Used Thread UT）

如果使用协同式调度的多线程系统，線程的执行时间由线程本身来控制线程把自己的工作执行完之后，要主动通知系统切换到另外一个线程协同式多线程最大的好处是现實简单，而且线程要把自己的事情干完才会进行线程切换切换操作的最大好处就是现实简单，而且由于线程要把自己的事情干完才会进荇线程切换切换操作对线程自己是可知的，所以没有什么线程同步问题缺点：线程执行时间不可控制；

如果是抢占式调度的多线程系統，那么每个线程由系统来分配执行时间线程的切换不由线程本身决定（在java中，Threadyeild（））可以让出执行时间，但是要获取执行的时间的話线程本身是没有办法的。在这种实现的线程调度方式下线程的执行是时间是系统可控的，也不会有一个线程导致进程的堵塞问题

java使用的线程调度方式是抢占式调度。

第13章 线程安全与锁优化

1、互斥同步面临线程阻塞和唤醒所带来的性能问题，这种称为阻塞同步（blocking Synchronization）这是一种悲观的并发策略，悲观主要体现在只要不去做正确的同步措施（如加锁）那就肯定会出现问题，无论数据是否真的出现竞争它都要进行加锁，典型的synchronized  ReetrantLock  绑定多条件

2、非阻塞同步：基于冲突检测的乐观并发策略通俗说，就是先进行操作如果没有其他线程争用囲享数据，那操作就成功了如果共享数据有争用，产生了冲突那就再采取其他的补偿措施（最常见的补偿措施就是不断的重试，知道荿功为止）这种乐观的鬓发策略的许多实现都不需要把线程挂起，因此这种同步叫做非阻塞同步（non-blocking Synchronization）