一些概念

数据类型

Java 虚拟机中，数据类型能够分为两类：根本类型和援用类型。根本类型的变量保留原始值，即：他代表的值就是数值自身；而援用类型的变量保留援用值。“援用值”代表了某个对象的援用，而不是对象自身，对象自身寄存在这个援用值所示意的地址的地位。

根本类型包含：byte,short,int,long,char,float,double,Boolean,returnAddress

援用类型包含：类类型，接口类型和数组。

堆与栈

堆和栈是程序运行的要害，很有必要把他们的关系说分明。

栈是运行时的单位，而堆是存储的单位。

栈解决程序的运行问题，即程序如何执行，或者说如何解决数据；堆解决的是数据存储的问题，即数据怎么放、放在哪儿。

在 Java 中一个线程就会相应有一个线程栈与之对应，这点很容易了解，因为不同的线程执行逻辑有所不同，因而须要一个独立的线程栈。而堆则是所有线程共享的。栈因为是运行单位，因而外面存储的信息都是跟以后线程（或程序）相干信息的。包含局部变量、程序运行状态、办法返回值等等；而堆只负责存储对象信息。

为什么要把堆和栈辨别进去呢？栈中不是也能够存储数据吗？

第一，从软件设计的角度看，栈代表了解决逻辑，而堆代表了数据。这样离开，使得解决逻辑更为清晰。分而治之的思维。这种隔离、模块化的思维在软件设计的方方面面都有体现。

第二，堆与栈的拆散，使得堆中的内容能够被多个栈共享（也能够了解为多个线程拜访同一个对象）。这种共享的收益是很多的。一方面这种共享提供了一种无效的数据交互方式 (如：共享内存)，另一方面，堆中的共享常量和缓存能够被所有栈拜访，节俭了空间。

第三，栈因为运行时的须要，比方保留零碎运行的上下文，须要进行地址段的划分。因为栈只能向上增长，因而就会限制住栈存储内容的能力。而堆不同，堆中的对象是能够依据须要动静增长的，因而栈和堆的拆分，使得动静增长成为可能，相应栈中只需记录堆中的一个地址即可。

第四，面向对象就是堆和栈的完满联合。其实，面向对象形式的程序与以前结构化的程序在执行上没有任何区别。然而，面向对象的引入，使得看待问题的思考形式产生了扭转，而更靠近于天然形式的思考。当咱们把对象拆开，你会发现，对象的属性其实就是数据，寄存在堆中；而对象的行为（办法），就是运行逻辑，放在栈中。咱们在编写对象的时候，其实即编写了数据结构，也编写的解决数据的逻辑。不得不抵赖，面向对象的设计，的确很美。

在 Java 中，Main 函数就是栈的起始点，也是程序的起始点。

程序要运行总是有一个终点的。同 C 语言一样，java 中的 Main 就是那个终点。无论什么 java 程序，找到 main 就找到了程序执行的入口：）

堆中存什么？栈中存什么？

堆中存的是对象。栈中存的是根本数据类型和堆中对象的援用。一个对象的大小是不可预计的，或者说是能够动态变化的，然而在栈中，一个对象只对应了一个 4btye 的援用（堆栈拆散的益处：））。

为什么不把根本类型放堆中呢？因为其占用的空间个别是 1~8 个字节——须要空间比拟少，而且因为是根本类型，所以不会呈现动静增长的状况——长度固定，因而栈中存储就够了，如果把他存在堆中是没有什么意义的（还会节约空间，前面阐明）。能够这么说，根本类型和对象的援用都是寄存在栈中，而且都是几个字节的一个数，因而在程序运行时，他们的解决形式是对立的。然而根本类型、对象援用和对象自身就有所区别了，因为一个是栈中的数据一个是堆中的数据。最常见的一个问题就是，Java 中参数传递时的问题。

Java 中的参数传递时传值呢？还是传援用？

要阐明这个问题，先要明确两点：

1. 不要试图与 C 进行类比，Java 中没有指针的概念

2. 程序运行永远都是在栈中进行的，因此参数传递时，只存在传递根本类型和对象援用的问题。不会间接传对象自身。

明确以上两点后。Java 在办法调用传递参数时，因为没有指针，所以它都是进行传值调用（这点能够参考 C 的传值调用）。因而，很多书外面都说 Java 是进行传值调用，这点没有问题，而且也简化的 C 中复杂性。

然而传援用的错觉是如何造成的呢？在运行栈中，根本类型和援用的解决是一样的，都是传值，所以，如果是传援用的办法调用，也同时能够了解为“传援用值”的传值调用，即援用的解决跟根本类型是齐全一样的。然而当进入被调用办法时，被传递的这个援用的值，被程序解释（或者查找）到堆中的对象，这个时候才对应到真正的对象。如果此时进行批改，批改的是援用对应的对象，而不是援用自身，即：批改的是堆中的数据。所以这个批改是能够放弃的了。

对象，从某种意义上说，是由根本类型组成的。能够把一个对象看作为一棵树，对象的属性如果还是对象，则还是一颗树（即非叶子节点），根本类型则为树的叶子节点。程序参数传递时，被传递的值自身都是不能进行批改的，然而，如果这个值是一个非叶子节点（即一个对象援用），则能够批改这个节点上面的所有内容。

堆和栈中，栈是程序运行最基本的货色。程序运行能够没有堆，然而不能没有栈。而堆是为栈进行数据存储服务，说白了堆就是一块共享的内存。不过，正是因为堆和栈的拆散的思维，才使得 Java 的垃圾回收成为可能。

Java 中，栈的大小通过 -Xss 来设置，当栈中存储数据比拟多时，须要适当调大这个值，否则会呈现 java.lang.StackOverflowError 异样。常见的呈现这个异样的是无奈返回的递归，因为此时栈中保留的信息都是办法返回的记录点。

Java 对象的大小

根本数据的类型的大小是固定的，这里就不多说了。对于非根本类型的 Java 对象，其大小就值得商讨。

在 Java 中，一个空 Object 对象的大小是 8byte，这个大小只是保留堆中一个没有任何属性的对象的大小。看上面语句：

Object ob = new Object();

这样在程序中实现了一个 Java 对象的生命，然而它所占的空间为：4byte+8byte。4byte 是下面局部所说的 Java 栈中保留援用的所须要的空间。而那 8byte 则是 Java 堆中对象的信息。因为所有的 Java 非根本类型的对象都须要默认继承 Object 对象，因而不管什么样的 Java 对象，其大小都必须是大于 8byte。

有了 Object 对象的大小，咱们就能够计算其余对象的大小了。

Class NewObject {
    int count;
    boolean flag;
    Object ob;
}
    其大小为：空对象大小 (8byte)+int 大小 (4byte)+Boolean 大小 (1byte)+ 空 Object 援用的大小 (4byte)=17byte。然而因为 Java 在对对象内存调配时都是以 8 的整数倍来分，因而大于 17byte 的最靠近 8 的整数倍的是 24，因而此对象的大小为 24byte。

这里须要留神一下根本类型的包装类型的大小。因为这种包装类型曾经成为对象了，因而须要把他们作为对象来对待。包装类型的大小至多是 12byte（申明一个空 Object 至多须要的空间），而且 12byte 没有蕴含任何无效信息，同时，因为 Java 对象大小是 8 的整数倍，因而一个根本类型包装类的大小至多是 16byte。这个内存占用是很恐怖的，它是应用根本类型的 N 倍（N>2），有些类型的内存占用更是夸大（轻易想下就晓得了）。因而，可能的话应尽量少应用包装类。在 JDK5.0 当前，因为退出了主动类型装换，因而，Java 虚构机会在存储方面进行相应的优化。

援用类型

对象援用类型分为强援用、软援用、弱援用和虚援用。

强援用: 就是咱们个别申明对象是时虚拟机生成的援用，强援用环境下，垃圾回收时须要严格判断以后对象是否被强援用，如果被强援用，则不会被垃圾回收

软援用: 软援用个别被做为缓存来应用。与强援用的区别是，软援用在垃圾回收时，虚构机会依据以后零碎的残余内存来决定是否对软援用进行回收。如果残余内存比拟缓和，则虚构机会回收软援用所援用的空间；如果残余内存绝对富裕，则不会进行回收。换句话说，虚拟机在产生 OutOfMemory 时，必定是没有软援用存在的。

弱援用: 弱援用与软援用相似，都是作为缓存来应用。但与软援用不同，弱援用在进行垃圾回收时，是肯定会被回收掉的，因而其生命周期只存在于一个垃圾回收周期内。

强援用不用说，咱们零碎个别在应用时都是用的强援用。而“软援用”和“弱援用”比拟少见。他们个别被作为缓存应用，而且个别是在内存大小比拟受限的状况下做为缓存。因为如果内存足够大的话，能够间接应用强援用作为缓存即可，同时可控性更高。因此，他们常见的是被应用在桌面利用零碎的缓存。

能够从不同的的角度去划分垃圾回收算法：

依照根本回收策略分

援用计数（Reference Counting）:

比拟古老的回收算法。原理是此对象有一个援用，即减少一个计数，删除一个援用则缩小一个计数。垃圾回收时，只用收集计数为 0 的对象。此算法最致命的是无奈解决循环援用的问题。

标记 - 革除（Mark-Sweep）:

此算法执行分两阶段。第一阶段从援用根节点开始标记所有被援用的对象，第二阶段遍历整个堆，把未标记的对象革除。此算法须要暂停整个利用，同时，会产生内存碎片。

复制（Copying）:

此算法把内存空间划为两个相等的区域，每次只应用其中一个区域。垃圾回收时，遍历以后应用区域，把正在应用中的对象复制到另外一个区域中。次算法每次只解决正在应用中的对象，因而复制老本比拟小，同时复制过来当前还能进行相应的内存整理，不会呈现“碎片”问题。当然，此算法的毛病也是很显著的，就是须要两倍内存空间。

标记 - 整顿（Mark-Compact）:

此算法联合了“标记 - 革除”和“复制”两个算法的长处。也是分两阶段，第一阶段从根节点开始标记所有被援用对象，第二阶段遍历整个堆，把革除未标记对象并且把存活对象“压缩”到堆的其中一块，按程序排放。此算法防止了“标记 - 革除”的碎片问题，同时也防止了“复制”算法的空间问题。

按分区看待的形式分

增量收集（Incremental Collecting）: 实时垃圾回收算法，即：在利用进行的同时进行垃圾回收。不晓得什么起因 JDK5.0 中的收集器没有应用这种算法的。

分代收集（Generational Collecting）: 基于对对象生命周期剖析后得出的垃圾回收算法。把对象分为年青代、年轻代、长久代，对不同生命周期的对象应用不同的算法（上述形式中的一个）进行回收。当初的垃圾回收器（从 J2SE1.2 开始）都是应用此算法的。

按零碎线程分

串行收集: 串行收集应用单线程解决所有垃圾回收工作, 因为无需多线程交互，实现容易，而且效率比拟高。然而，其局限性也比拟显著，即无奈应用多处理器的劣势，所以此收集适宜单处理器机器。当然，此收集器也能够用在小数据量（100M 左右）状况下的多处理器机器上。

并行收集: 并行收集应用多线程解决垃圾回收工作，因此速度快，效率高。而且实践上 CPU 数目越多，越能体现出并行收集器的劣势。

并发收集: 绝对于串行收集和并行收集而言，后面两个在进行垃圾回收工作时，须要暂停整个运行环境，而只有垃圾回收程序在运行，因而，零碎在垃圾回收时会有显著的暂停，而且暂停工夫会因为堆越大而越长。

如何辨别垃圾

下面说到的“援用计数”法，通过统计管制生成对象和删除对象时的援用数来判断。垃圾回收程序收集计数为 0 的对象即可。然而这种办法无奈解决循环援用。所以，起初实现的垃圾判断算法中，都是从程序运行的根节点登程，遍历整个对象援用，查找存活的对象。那么在这种形式的实现中，垃圾回收从哪儿开始的呢？即，从哪儿开始查找哪些对象是正在被以后零碎应用的。下面剖析的堆和栈的区别，其中栈是真正进行程序执行中央，所以要获取哪些对象正在被应用，则须要从 Java 栈开始。同时，一个栈是与一个线程对应的，因而，如果有多个线程的话，则必须对这些线程对应的所有的栈进行查看。

同时，除了栈外，还有零碎运行时的寄存器等，也是存储程序运行数据的。这样，以栈或寄存器中的援用为终点，咱们能够找到堆中的对象，又从这些对象找到对堆中其余对象的援用，这种援用逐渐扩大，最终以 null 援用或者根本类型完结，这样就造成了一颗以 Java 栈中援用所对应的对象为根节点的一颗对象树，如果栈中有多个援用，则最终会造成多颗对象树。在这些对象树上的对象，都是以后零碎运行所须要的对象，不能被垃圾回收。而其余残余对象，则能够视为无奈被援用到的对象，能够被当做垃圾进行回收。

因而，垃圾回收的终点是一些根对象（java 栈, 动态变量, 寄存器 …）。而最简略的 Java 栈就是 Java 程序执行的 main 函数。这种回收形式，也是下面提到的“标记 - 革除”的回收形式

如何解决碎片

因为不同 Java 对象存活工夫是不肯定的，因而，在程序运行一段时间当前，如果不进行内存整理，就会呈现零散的内存碎片。碎片最间接的问题就是会导致无奈调配大块的内存空间，以及程序运行效率升高。所以，在下面提到的根本垃圾回收算法中，“复制”形式和“标记 - 整顿”形式，都能够解决碎片的问题。

如何解决同时存在的对象创立和对象回收问题

垃圾回收线程是回收内存的，而程序运行线程则是耗费（或调配）内存的，一个回收内存，一个分配内存，从这点看，两者是矛盾的。因而，在现有的垃圾回收形式中，要进行垃圾回收前，个别都须要暂停整个利用（即：暂停内存的调配），而后进行垃圾回收，回收实现后再持续利用。这种实现形式是最间接，而且最无效的解决二者矛盾的形式。

然而这种形式有一个很显著的弊病，就是当堆空间继续增大时，垃圾回收的工夫也将会相应的继续增大，对应利用暂停的工夫也会相应的增大。一些对相应工夫要求很高的利用，比方最大暂停工夫要求是几百毫秒，那么当堆空间大于几个 G 时，就很有可能超过这个限度，在这种状况下，垃圾回收将会成为零碎运行的一个瓶颈。为解决这种矛盾，有了并发垃圾回收算法，应用这种算法，垃圾回收线程与程序运行线程同时运行。在这种形式下，解决了暂停的问题，然而因为须要在新生成对象的同时又要回收对象，算法复杂性会大大增加，零碎的解决能力也会相应升高，同时，“碎片”问题将会比拟难解决。

为什么要分代

分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因而，不同生命周期的对象能够采取不同的收集形式，以便进步回收效率。

在 Java 程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相干，比方 Http 申请中的 Session 对象、线程、Socket 连贯，这类对象跟业务间接挂钩，因而生命周期比拟长。然而还有一些对象，次要是程序运行过程中生成的长期变量，这些对象生命周期会比拟短，比方：String 对象，因为其不变类的个性，零碎会产生大量的这些对象，有些对象甚至只用一次即可回收。

试想，在不进行对象存活工夫辨别的状况下，每次垃圾回收都是对整个堆空间进行回收，破费工夫绝对会长，同时，因为每次回收都须要遍历所有存活对象，但实际上，对于生命周期长的对象而言，这种遍历是没有成果的，因为可能进行了很屡次遍历，然而他们仍旧存在。因而，分代垃圾回收采纳分治的思维，进行代的划分，把不同生命周期的对象放在不同代上，不同代上采纳最适宜它的垃圾回收形式进行回收。

如何分代

如图所示：

虚拟机中的共划分为三个代：年老代（Young Generation）、年轻点（Old Generation）和长久代（Permanent Generation）。其中长久代次要寄存的是 Java 类的类信息，与垃圾收集要收集的 Java 对象关系不大。年老代和年轻代的划分是对垃圾收集影响比拟大的。

年老代:

所有新生成的对象首先都是放在年老代的。年老代的指标就是尽可能疾速的收集掉那些生命周期短的对象。年老代分三个区。一个 Eden 区，两个 Survivor 区 (一般而言)。大部分对象在 Eden 区中生成。当 Eden 区满时，还存活的对象将被复制到 Survivor 区（两个中的一个），当这个 Survivor 区满时，此区的存活对象将被复制到另外一个 Survivor 区，当这个 Survivor 去也满了的时候，从第一个 Survivor 区复制过去的并且此时还存活的对象，将被复制“年老区 (Tenured)”。须要留神，Survivor 的两个区是对称的，没先后关系，所以同一个区中可能同时存在从 Eden 复制过去 对象，和从前一个 Survivor 复制过去的对象，而复制到年老区的只有从第一个 Survivor 去过去的对象。而且，Survivor 区总有一个是空的。同时，依据程序须要，Survivor 区是能够配置为多个的（多于两个），这样能够减少对象在年老代中的存在工夫，缩小被放到年轻代的可能。

年轻代:

在年老代中经验了 N 次垃圾回收后依然存活的对象，就会被放到年轻代中。因而，能够认为年轻代中寄存的都是一些生命周期较长的对象。

长久代:

用于寄存动态文件，现在 Java 类、办法等。长久代对垃圾回收没有显著影响，然而有些利用可能动静生成或者调用一些 class，例如 Hibernate 等，在这种时候须要设置一个比拟大的长久代空间来寄存这些运行过程中新增的类。长久代大小通过 -XX:MaxPermSize= 进行设置。

什么状况下触发垃圾回收

因为对象进行了分代解决，因而垃圾回收区域、工夫也不一样。GC 有两种类型：Scavenge GC 和 Full GC。

Scavenge GC

个别状况下，当新对象生成，并且在 Eden 申请空间失败时，就会触发 Scavenge GC，对 Eden 区域进行 GC，清除非存活对象，并且把尚且存活的对象挪动到 Survivor 区。而后整顿 Survivor 的两个区。这种形式的 GC 是对年老代的 Eden 区进行，不会影响到年轻代。因为大部分对象都是从 Eden 区开始的，同时 Eden 区不会调配的很大，所以 Eden 区的 GC 会频繁进行。因此，个别在这里须要应用速度快、效率高的算法，使 Eden 去能尽快闲暇进去。

Full GC

对整个堆进行整顿，包含 Young、Tenured 和 Perm。Full GC 因为须要对整个对进行回收，所以比 Scavenge GC 要慢，因而应该尽可能减少 Full GC 的次数。在对 JVM 调优的过程中，很大一部分工作就是对于 FullGC 的调节。有如下起因可能导致 Full GC：

· 年轻代（Tenured）被写满
· 长久代（Perm）被写满 
· System.gc() 被显示调用 
·上一次 GC 之后 Heap 的各域调配策略动态变化 

分代垃圾回收流程示意

抉择适合的垃圾收集算法

用单线程解决所有垃圾回收工作，因为无需多线程交互，所以效率比拟高。然而，也无奈应用多处理器的劣势，所以此收集器适宜单处理器机器。当然，此收集器也能够用在小数据量（100M 左右）状况下的多处理器机器上。能够应用 -XX:+UseSerialGC 关上。

对年老代进行并行垃圾回收，因而能够缩小垃圾回收工夫。个别在多线程多处理器机器上应用。应用 -XX:+UseParallelGC. 关上。并行收集器在 J2SE5.0 第六 6 更新上引入，在 Java SE6.0 中进行了加强 – 能够对年轻代进行并行收集。如果年轻代不应用并发收集的话，默认是应用单线程进行垃圾回收，因而会制约扩大能力。应用 -XX:+UseParallelOldGC 关上。

应用 -XX:ParallelGCThreads= 设置并行垃圾回收的线程数。此值能够设置与机器处理器数量相等。

此收集器能够进行如下配置：

最大垃圾回收暂停: 指定垃圾回收时的最长暂停工夫，通过 -XX:MaxGCPauseMillis=\(<N>\) 指定。>\(<N>\) 为毫秒. 如果指定了此值的话，堆大小和垃圾回收相干参数会进行调整以达到指定值。设定此值可能会缩小利用的吞吐量。

吞吐量: 吞吐量为垃圾回收工夫与非垃圾回收工夫的比值，通过 -XX:GCTimeRatio=\(<N>\) 来设定，公 > 式为 1 /（1+N）。例如，-XX:GCTimeRatio=19 时，示意 5% 的工夫用于垃圾回收。默认状况为 99，即 >1% 的工夫用于垃圾回收。

并发收集器

能够保障大部分工作都并发进行（利用不进行），垃圾回收只暂停很少的工夫，此收集器适宜对响应工夫要求比拟高的中、大规模利用。应用 -XX:+UseConcMarkSweepGC 关上。

并发收集器次要缩小年轻代的暂停工夫，他在利用不进行的状况下应用独立的垃圾回收线程，跟踪可达对象。在每个年轻代垃圾回收周期中，在收集初期并发收集器 会对整个利用进行简短的暂停，在收集中还会再暂停一次。第二次暂停会比第一次稍长，在此过程中多个线程同时进行垃圾回收工作。

并发收集器应用处理器换来短暂的进展工夫。在一个 N 个处理器的零碎上，并发收集局部应用 K / N 个可用处理器进行回收，个别状况下 1 <=K<=N/4。

在只有一个处理器的主机上应用并发收集器，设置为 incremental mode 模式也可取得较短的进展工夫。

浮动垃圾：因为在利用运行的同时进行垃圾回收，所以有些垃圾可能在垃圾回收进行实现时产生，这样就造成了“Floating Garbage”，这些垃圾须要在下次垃圾回收周期时能力回收掉。所以，并发收集器个别须要 20% 的预留空间用于这些浮动垃圾。

Concurrent Mode Failure：并发收集器在利用运行时进行收集，所以须要保障堆在垃圾回收的这段时间有足够的空间供程序应用，否则，垃圾回收还未实现，堆空间先满了。这种状况下将会产生“并发模式失败”，此时整个利用将会暂停，进行垃圾回收。

启动并发收集器：因为并发收集在利用运行时进行收集，所以必须保障收集实现之前有足够的内存空间供程序应用，否则会呈现“Concurrent Mode Failure”。通过设置 -XX:CMSInitiatingOccupancyFraction= 指定还有多少残余堆时开始执行并发收集

小结

串行处理器：

• 实用状况：数据量比拟小（100M 左右）；单处理器下并且对响应工夫无要求的利用。
• 毛病：只能用于小型利用

并行处理器：

• 实用状况：“对吞吐量有高要求”，多 CPU、对利用响应工夫无要求的中、大型利用。举例：后盾解决、科学计算。
• 毛病：垃圾收集过程中利用响应工夫可能加长

并发处理器：

• 实用状况：“对响应工夫有高要求”，多 CPU、对利用响应工夫有较高要求的中、大型利用。举例：Web 服务器 / 应用服务器、电信替换、集成开发环境。

以下配置次要针对分代垃圾回收算法而言。

堆大小设置

年老代的设置很要害
JVM 中最大堆大小有三方面限度：相干操作系统的数据模型（32-bt 还是 64-bit）限度；零碎的可用虚拟内存限度；零碎的可用物理内存限度。32 位零碎下，个别限度在 1.5G~2G；64 为操作系统对内存无限度。在 Windows Server 2003 零碎，3.5G 物理内存，JDK5.0 下测试，最大可设置为 1478m。
典型设置：

java -Xmx3550m -Xms3550m -Xmn2g –Xss128k

-Xmx3550m：设置 JVM 最大可用内存为 3550M。-Xms3550m：设置 JVM 促使内存为 3550m。此值能够设置与 -Xmx 雷同，以防止每次垃圾回收实现后 JVM 从新分配内存。-Xmn2g：设置年老代大小为 2G。整个堆大小 = 年老代大小 + 年轻代大小 + 长久代大小。长久代个别固定大小为 64m，所以增大年老代后，将会减小年轻代大小。此值对系统性能影响较大，Sun 官网举荐配置为整个堆的 3 /8。-Xss128k：设置每个线程的堆栈大小。JDK5.0 当前每个线程堆栈大小为 1M，以前每个线程堆栈大小为 256K。更具利用的线程所需内存大小进行调整。在雷同物理内存下，减小这个值能生成更多的线程。然而操作系统对一个过程内的线程数还是有限度的，不能有限生成，经验值在 3000~5000 左右。

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 会依据以后系统配置进行判断。

吞吐量优先的并行收集器

如上文所述，并行收集器次要以达到肯定的吞吐量为指标，实用于科学技术和后盾解决等。

典型配置：

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

-XX:+UseParallelGC：抉择垃圾收集器为并行收集器。此配置仅对年老代无效。即上述配置下，年老代应用并发收集，而年轻代仍旧应用串行收集。-XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。

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

-XX:+UseParallelOldGC：配置年轻代垃圾收集形式为并行收集。JDK6.0 反对对年轻代并行收集。

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

-XX:MaxGCPauseMillis=100: 设置每次年老代垃圾回收的最长工夫，如果无奈满足此工夫，JVM 会主动调整年老代大小，以满足此值。

n java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy

-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会主动抉择年老代区大小和相应的 Survivor 区比例，以达到目标零碎规定的最低相应工夫或者收集频率等，此值倡议应用并行收集器时，始终关上。

响应工夫优先的并发收集器

如上文所述，并发收集器次要是保证系统的响应工夫，缩小垃圾收集时的进展工夫。实用于应用服务器、电信畛域等。

典型配置：

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

-XX:+UseConcMarkSweepGC：设置年轻代为并发收集。测试中配置这个当前，-XX:NewRatio= 4 的配置生效了，起因不明。所以，此时年老代大小最好用 -Xmn 设置。-XX:+UseParNewGC: 设置年老代为并行收集。可与 CMS 收集同时应用。JDK5.0 以上，JVM 会依据系统配置自行设置，所以无需再设置此值。

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

-XX:CMSFullGCsBeforeCompaction：因为并发收集器不对内存空间进行压缩、整顿，所以运行一段时间当前会产生“碎片”，使得运行效率升高。此值设置运行多少次 GC 当前对内存空间进行压缩、整顿。-XX:+UseCMSCompactAtFullCollection：关上对年轻代的压缩。可能会影响性能，然而能够打消碎片 

辅助信息

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

-XX:+PrintGC：输入模式：[GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]

-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]

-XX:+PrintGCTimeStamps -XX:+PrintGC：PrintGCTimeStamps 可与下面两个混合应用
输入模式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]

-XX:+PrintGCApplicationConcurrentTime：打印每次垃圾回收前，程序未中断的执行工夫。可与下面混合应用。输入模式：Application time: 0.5291524 seconds

-XX:+PrintGCApplicationStoppedTime：打印垃圾回收期间程序暂停的工夫。可与下面混合应用。输入模式：Total time for which application threads were stopped: 0.0468229 seconds

-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: 与下面几个配合应用，把相干日志信息记录到文件以便剖析。

常见配置汇总

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

收集器设置
-XX:+UseSerialGC: 设置串行收集器
-XX:+UseParallelGC: 设置并行收集器
-XX:+UseParalledlOldGC: 设置并行年轻代收集器
-XX:+UseConcMarkSweepGC: 设置并发收集器

垃圾回收统计信息
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:filename

并行收集器设置
-XX:ParallelGCThreads=n: 设置并行收集器收集时应用的 CPU 数。并行收集线程数。
-XX:MaxGCPauseMillis=n: 设置并行收集最大暂停工夫
-XX:GCTimeRatio=n: 设置垃圾回收工夫占程序运行工夫的百分比。公式为 1 /(1+n)

并发收集器设置
-XX:+CMSIncrementalMode: 设置为增量模式。实用于单 CPU 状况。
-XX:ParallelGCThreads=n: 设置并发收集器年老代收集形式为并行收集时，应用的 CPU 数。并行收集线程数。

调优总结

年老代大小抉择

响应工夫优先的利用：尽可能设大，直到靠近零碎的最低响应工夫限度（依据理论状况抉择）。在此种状况下，年老代收集产生的频率也是最小的。同时，缩小达到年轻代的对象。

吞吐量优先的利用：尽可能的设置大，可能达到 Gbit 的水平。因为对响应工夫没有要求，垃圾收集能够并行进行，个别适宜 8CPU 以上的利用。

年轻代大小抉择

响应工夫优先的利用：年轻代应用并发收集器，所以其大小须要小心设置，个别要思考并发会话率和会话持续时间等一些参数。如果堆设置小了，能够会造成内存碎片、高回收频率以及利用暂停而应用传统的标记革除形式；如果堆大了，则须要较长的收集工夫。最优化的计划，个别须要参考以下数据取得：

1. 并发垃圾收集信息
2. 长久代并发收集次数
3. 传统 GC 信息
4. 花在年老代和年轻代回收上的工夫比例
   缩小年老代和年轻代破费的工夫，个别会进步利用的效率

吞吐量优先的利用

个别吞吐量优先的利用都有一个很大的年老代和一个较小的年轻代。起因是，这样能够尽可能回收掉大部分短期对象，缩小中期的对象，而年轻代尽寄存长期存活对象。

较小堆引起的碎片问题

因为年轻代的并发收集器应用标记、革除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样能够调配给较大的对象。然而，当堆空间较小时，运行一段时间当前，就会呈现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会进行，而后应用传统的标记、革除形式进行回收。如果呈现“碎片”，可能须要进行如下配置：

1. -XX:+UseCMSCompactAtFullCollection：应用并发收集器时，开启对年轻代的压缩。
2. -XX:CMSFullGCsBeforeCompaction=0：下面配置开启的状况下，这里设置多少次 Full GC 后，对年轻代进行压缩

垃圾回收的瓶颈

传统分代垃圾回收形式，曾经在肯定水平上把垃圾回收给利用带来的累赘降到了最小，把利用的吞吐量推到了一个极限。然而他无奈解决的一个问题，就是 Full GC 所带来的利用暂停。在一些对实时性要求很高的利用场景下，GC 暂停所带来的申请沉积和申请失败是无奈承受的。这类利用可能要求申请的返回工夫在几百甚至几十毫秒以内，如果分代垃圾回收形式要达到这个指标，只能把最大堆的设置限度在一个绝对较小范畴内，然而这样有限度了利用自身的解决能力，同样也是不可接管的。

分代垃圾回收形式的确也思考了实时性要求而提供了并发回收器，反对最大暂停工夫的设置，然而受限于分代垃圾回收的内存划分模型，其成果也不是很现实。

为了达到实时性的要求（其实 Java 语言最后的设计也是在嵌入式零碎上的），一种新垃圾回收形式跃然纸上，它既反对短的暂停工夫，又反对大的内存空间调配。能够很好的解决传统分代形式带来的问题。

增量收集的演进

增量收集的形式在实践上能够解决传统分代形式带来的问题。增量收集把对堆空间划分成一系列内存块，应用时，先应用其中一部分（不会全副用完），垃圾收集时把之前用掉的局部中的存活对象再放到前面没有用的空间中，这样能够实现始终边应用边收集的成果，防止了传统分代形式整个应用完了再暂停的回收的状况。

当然，传统分代收集形式也提供了并发收集，然而他有一个很致命的中央，就是把整个堆做为一个内存块，这样一方面会造成碎片（无奈压缩），另一方面他的每次收集都是对整个堆的收集，无奈进行抉择，在暂停工夫的管制上还是很弱。而增量形式，通过内存空间的分块，恰好能够解决下面问题。

Garbage Firest（G1）

这部分的内容次要参考这里，这篇文章算是对 G1 算法论文的解读。我也没加什么货色了。

指标

从设计指标看 G1 齐全是为了大型利用而筹备的。

 反对很大的堆
高吞吐量
  -- 反对多 CPU 和垃圾回收线程
  -- 在主线程暂停的状况下，应用并行收集
  -- 在主线程运行的状况下，应用并发收集
实时指标：可配置在 N 毫秒内最多只占用 M 毫秒的工夫进行垃圾回收 

当然 G1 要达到实时性的要求，绝对传统的分代回收算法，在性能上会有一些损失。

算法详解

G1 堪称博采众家之长，力求达到一种完满。他汲取了增量收集长处，把整个堆划分为一个一个等大小的区域（region）。内存的回收和划分都以 region 为单位；同时，他也汲取了 CMS 的特点，把这个垃圾回收过程分为几个阶段，扩散一个垃圾回收过程；而且，G1 也认同分代垃圾回收的思维，认为不同对象的生命周期不同，能够采取不同收集形式，因而，它也反对分代的垃圾回收。为了达到对回收工夫的可预计性，G1 在扫描了 region 当前，对其中的沉闷对象的大小进行排序，首先会收集那些沉闷对象小的 region，以便疾速回收空间（要复制的沉闷对象少了），因为沉闷对象小，外面能够认为少数都是垃圾，所以这种形式被称为 Garbage First（G1）的垃圾回收算法，即：垃圾优先的回收。

回收步骤：

初始标记（Initial Marking）

G1 对于每个 region 都保留了两个标识用的 bitmap，一个为 previous marking bitmap，一个为 next marking bitmap，bitmap 中蕴含了一个 bit 的地址信息来指向对象的起始点。

开始 Initial Marking 之前，首先并发的清空 next marking bitmap，而后进行所有利用线程，并扫描标识出每个 region 中 root 可间接拜访到的对象，将 region 中 top 的值放入 next top at mark start（TAMS）中，之后复原所有利用线程。

触发这个步骤执行的条件为：

G1 定义了一个 JVM Heap 大小的百分比的阀值，称为 h，另外还有一个 H，H 的值为 (1-h)*Heap Size，目前这个 h 的值是固定的，后续 G1 兴许会将其改为动静的，依据 jvm 的运行状况来动静的调整，在分代形式下，G1 还定义了一个 u 以及 soft limit，soft limit 的值为 H -u*Heap Size，当 Heap 中应用的内存超过了 soft limit 值时，就会在一次 clean up 执行结束后在利用容许的 GC 暂停工夫范畴内尽快的执行此步骤；在 pure 形式下，G1 将 marking 与 clean up 组成一个环，以便 clean up 能充沛的应用 marking 的信息，当 clean up 开始回收时，首先回收可能带来最多内存空间的 regions，当通过屡次的 clean up，回收到没多少空间的 regions 时，G1 从新初始化一个新的 marking 与 clean up 形成的环。

并发标记（Concurrent Marking）

依照之前 Initial Marking 扫描到的对象进行遍历，以辨认这些对象的上层对象的沉闷状态，对于在此期间利用线程并发批改的对象的以来关系则记录到 remembered set logs 中，新创建的对象则放入比 top 值更高的地址区间中，这些新创建的对象默认状态即为沉闷的，同时批改 top 值。

最终标记暂停（Final Marking Pause）

当利用线程的 remembered set logs 未满时，是不会放入 filled RS buffers 中的，在这样的状况下，这些 remebered set logs 中记录的 card 的批改就会被更新了，因而须要这一步，这一步要做的就是把利用线程中存在的 remembered set logs 的内容进行解决，并相应的批改 remembered sets，这一步须要暂停利用，并行的运行。

存活对象计算及革除（Live Data Counting and Cleanup）

值得注意的是，在 G1 中，并不是说 Final Marking Pause 执行完了，就必定执行 Cleanup 这步的，因为这步须要暂停利用，G1 为了可能达到准实时的要求，须要依据用户指定的最大的 GC 造成的暂停工夫来正当的布局什么时候执行 Cleanup，另外还有几种状况也是会触发这个步骤的执行的：

G1 采纳的是复制办法来进行收集，必须保障每次的”to space”的空间都是够的，因而 G1 采取的策略是当曾经应用的内存空间达到了 H 时，就执行 Cleanup 这个步骤；对于 full-young 和 partially-young 的分代模式的 G1 而言，则还有状况会触发 Cleanup 的执行，full-young 模式下，G1 依据利用可承受的暂停工夫、回收 young regions 须要耗费的工夫来估算出一个 yound regions 的数量值，当 JVM 中调配对象的 young regions 的数量达到此值时，Cleanup 就会执行；partially-young 模式下，则会尽量频繁的在利用可承受的暂停工夫范畴内执行 Cleanup，并最大限度的去执行 non-young regions 的 Cleanup。

瞻望

当前 JVM 的调优或者跟多须要针对 G1 算法进行调优了。

JVM 调优工具

Jconsole，jProfile，VisualVM

Jconsole : jdk 自带，性能简略，然而能够在零碎有肯定负荷的状况下应用。对垃圾回收算法有很具体的跟踪。

JProfiler：商业软件，须要付费。功能强大。

VisualVM：JDK 自带，功能强大，与 JProfiler 相似。举荐。

如何调优

察看内存开释状况、汇合类查看、对象树

下面这些调优工具都提供了弱小的性能，然而总的来说个别分为以下几类性能

堆信息查看

 可查看堆空间大小调配（年老代、年轻代、长久代调配）提供即时的垃圾回收性能
垃圾监控（长时间监控回收状况）

 查看堆内类、对象信息查看：数量、类型等 

 对象援用状况查看 

有了堆信息查看方面的性能，咱们个别能够顺利解决以下问题：

• 年轻代年老代大小划分是否正当
• 内存透露
• 垃圾回收算法设置是否正当

线程监控

 线程信息监控：零碎线程数量。线程状态监控：各个线程都处在什么样的状态下 

Dump 线程详细信息：查看线程外部运行状况
死锁查看 

热点剖析

CPU 热点：查看零碎哪些办法占用的大量 CPU 工夫

内存热点：查看哪些对象在零碎中数量最大（肯定工夫内存活对象和销毁对象一起统计）

这两个货色对于系统优化很有帮忙。咱们能够依据找到的热点，有针对性的进行零碎的瓶颈查找和进行系统优化，而不是漫无目的的进行所有代码的优化。

快照
快照是零碎运行到某一时刻的一个定格。在咱们进行调优的时候，不可能用眼睛去跟踪所有零碎变动，依赖快照性能，咱们就能够进行零碎两个不同运行时刻，对象（或类、线程等）的不同，以便疾速找到问题

举例说，我要查看零碎进行垃圾回收当前，是否还有该发出的对象被脱漏下来的了。那么，我能够在进行垃圾回收前后，别离进行一次堆状况的快照，而后比照两次快照的对象状况。

内存透露查看

内存透露是比拟常见的问题，而且解决办法也比拟通用，这里能够重点说一下，而线程、热点方面的问题则是具体问题具体分析了。

内存透露个别能够了解为系统资源（各方面的资源，堆、栈、线程等）在谬误应用的状况下，导致应用结束的资源无奈回收（或没有回收），从而导致新的资源分配申请无奈实现，引起零碎谬误。

内存透露对系统危害比拟大，因为他能够间接导致系统的解体。

须要区别一下，内存透露和零碎超负荷两者是有区别的，尽管可能导致的最终后果是一样的。内存透露是用完的资源没有回收引起谬误，而零碎超负荷则是零碎的确没有那么多资源能够调配了（其余的资源都在应用）。

年轻代堆空间被占满

异样：java.lang.OutOfMemoryError: Java heap space

阐明：

这是最典型的内存透露形式，简略说就是所有堆空间都被无奈回收的垃圾对象占满，虚拟机无奈再在调配新空间。
如上图所示，这是十分典型的内存透露的垃圾回收状况图。所有峰值局部都是一次垃圾回收点，所有谷底局部示意是一次垃圾回收后残余的内存。连贯所有谷底的点，能够发现一条由底到高的线，这阐明，随工夫的推移，零碎的堆空间被一直占满，最终会占满整个堆空间。因而能够初步认为零碎外部可能有内存透露。（下面的图仅供示例，在理论状况下收集数据的工夫须要更长，比方几个小时或者几天）

解决：

这种形式解决起来也比拟容易，个别就是依据垃圾回收前后状况比照，同时依据对象援用状况（常见的汇合对象援用）剖析，根本都能够找到透露点。

长久代被占满

异样：java.lang.OutOfMemoryError: PermGen space

阐明：

Perm 空间被占满。无奈为新的 class 调配存储空间而引发的异样。这个异样以前是没有的，然而在 Java 反射大量应用的明天这个异样比拟常见了。次要起因就是大量动静反射生成的类一直被加载，最终导致 Perm 区被占满。

更可怕的是，不同的 classLoader 即使应用了雷同的类，然而都会对其进行加载，相当于同一个货色，如果有 N 个 classLoader 那么他将会被加载 N 次。因而，某些状况下，这个问题根本视为无解。当然，存在大量 classLoader 和大量反射类的状况其实也不多。
解决：

1. -XX:MaxPermSize=16m
2. 换用 JDK。比方 JRocket。

堆栈溢出

异样：java.lang.StackOverflowError

阐明：这个就不多说了，个别就是递归没返回，或者循环调用造成

线程堆栈满

异样：Fatal: Stack size too small

阐明：java 中一个线程的空间大小是有限度的。JDK5.0 当前这个值是 1M。与这个线程相干的数据将会保留在其中。然而当线程空间满了当前，将会呈现下面异样。

解决：减少线程栈大小。-Xss2m。但这个配置无奈解决基本问题，还要看代码局部是否有造成透露的局部。

零碎内存被占满

异样：java.lang.OutOfMemoryError: unable to create new native thread

阐明：

这个异样是因为操作系统没有足够的资源来产生这个线程造成的。零碎创立线程时，除了要在 Java 堆中分配内存外，操作系统自身也须要分配资源来创立线程。因而，当线程数量大到肯定水平当前，堆中或者还有空间，然而操作系统调配不出资源来了，就呈现这个异样了。

调配给 Java 虚拟机的内存愈多，零碎残余的资源就越少，因而，当零碎内存固定时，调配给 Java 虚拟机的内存越多，那么，零碎总共可能产生的线程也就越少，两者成反比的关系。同时，能够通过批改 -Xss 来缩小调配给单个线程的空间，也能够减少零碎总共内生产的线程数。

解决：

1. 从新设计零碎缩小线程数量。
2. 线程数量不能缩小的状况下，通过 -Xss 减小单个线程大小。以便能生产更多的线程。

垃圾回收的悖论

所谓“成也萧何败萧何”。Java 的垃圾回收的确带来了很多益处，为开发带来了便当。然而在一些高性能、高并发的状况下，垃圾回收确成为了制约 Java 利用的瓶颈。目前 JDK 的垃圾回收算法，始终无奈解决垃圾回收时的暂停问题，因为这个暂停重大影响了程序的相应工夫，造成拥塞或沉积。这也是后续 JDK 减少 G1 算法的一个重要起因。

当然，下面是从技术角度登程解决垃圾回收带来的问题，然而从零碎设计方面咱们就须要问一下了：

 咱们须要调配如此大的内存空间给利用吗？咱们是否可能通过无效应用内存而不是通过扩充内存的形式来设计咱们的零碎呢？

咱们的内存中都放了什么

内存中须要放什么呢？集体认为，内存中须要放的是你的利用须要在不久的未来再次用到到的货色。想想看，如果你在未来不必这些货色，何必放内存呢？放文件、数据库不是更好？这些货色个别包含：

1. 零碎运行时业务相干的数据。比方 web 利用中的 session、即时消息的 session 等。这些数据个别在一个用户拜访周期或者一个应用过程中都须要存在。
2. 缓存。缓存就比拟多了，你所要快速访问的都能够放这外面。其实下面的业务数据也能够了解为一种缓存。
3. 线程。

因而，咱们是不是能够这么认为，如果咱们不把业务数据和缓存放在 JVM 中，或者把他们独立进去，那么 Java 利用应用时所需的内存将会大大减少，同时垃圾回收工夫也会相应缩小。

我认为这是可能的。

解决之道

数据库、文件系统

把所有数据都放入数据库或者文件系统，这是一种最为简略的形式。在这种形式下，Java 利用的内存基本上等于解决一次峰值并发申请所需的内存。数据的获取都在每次申请时从数据库和文件系统中获取。也能够了解为，一次业务拜访当前，所有对象都能够进行回收了。

这是一种内存应用最无效的形式，然而从利用角度来说，这种形式很低效。

内存 - 硬盘映射

下面的问题是因为咱们应用了文件系统带来了低效。然而如果咱们不是读写硬盘，而是写内存的话效率将会进步很多。

数据库和文件系统都是实实在在进行了长久化，然而当咱们并不需要这样长久化的时候，咱们能够做一些变通——把内存当硬盘使。

内存 - 硬盘映射很好很弱小，既用了缓存又对 Java 利用的内存应用又没有影响。Java 利用还是 Java 利用，他只晓得读写的还是文件，然而实际上是内存。

这种形式兼得的 Java 利用与缓存两方面的益处。memcached 的宽泛应用也正是这一类的代表。

同一机器部署多个 JVM

这也是一种很好的形式，能够分为纵拆和横拆。纵拆能够了解为把 Java 利用划分为不同模块，各个模块应用一个独立的 Java 过程。而横拆则是同样性能的利用部署多个 JVM。

通过部署多个 JVM，能够把每个 JVM 的内存管制一个垃圾回收能够忍耐的范畴内即可。然而这相当于进行了分布式的解决，其额定带来的复杂性也是须要评估的。另外，也有反对分布式的这种 JVM 能够思考，不要要钱哦：）

程序控制的对象生命周期
这种形式是现实当中的形式，目前的虚拟机还没有，纯属假如。即：思考由编程形式配置哪些对象在垃圾收集过程中能够间接跳过，缩小垃圾回收线程遍历标记的工夫。

这种形式相当于在编程的时候通知虚拟机某些对象你能够在 * 工夫后在进行收集或者由代码标识能够收集了（相似 C、C++），在这之前你即使去遍历他也是没有成果的，他必定是还在被援用的。

这种形式如果 JVM 能够实现，集体认为将是一个飞跃，Java 即有了垃圾回收的劣势，又有了 C、C++ 对内存的可控性。

线程调配

Java 的阻塞式的线程模型基本上能够摈弃了，目前成熟的 NIO 框架也比拟多了。阻塞式 IO 带来的问题是线程数量的线性增长，而 NIO 则能够转换成为常数线程。因而，对于服务端的利用而言，NIO 还是惟一抉择。不过，JDK7 中为咱们带来的 AIO 是否能让人眼前一亮呢？咱们刮目相待。

其余的 JDK

本文说的都是 Sun 的 JDK，目前常见的 JDK 还有 JRocket 和 IBM 的 JDK。其中 JRocket 在 IO 方面比 Sun 的高很多，不过 Sun JDK6.0 当前进步也很大。而且 JRocket 在垃圾回收方面，也具备劣势，其可设置垃圾回收的最大暂停工夫也是很吸引人的。不过，零碎 Sun 的 G1 实现当前，在这方面会有一个质的飞跃。

 能整顿出下面一些货色，也是因为站在伟人的肩上。上面是一些参考资料，供大家学习，大家有更好的，能够持续欠缺：）

· Java 实践与实际: 垃圾收集简史

·《深刻 Java 虚拟机》。尽管过来了很多年，但这本书仍旧是经典。

这里是本系列的最初一篇了，很快乐大家可能喜爱这系列的文章。期间也提了很多问题，其中有些是我之前没有想到的或者思考欠妥的，感激提出这些问题的敌人，我也学到的不少货色。

关注公众号:java 宝典