JVM对象分配&回收算法

原本标题党想写成《深刻JVM》，不过不太敢写，我想一小篇博客我想还不足以说明JVM，在本文中，会就我所知给你们介绍JVM的不少内部知识，概念会相对较粗，由于太细的内容要写，这里确定写不出来；本文主要偏重理论，没有什么实践，中间除一些官方资料外，还有部分自身的理解，因此请你们不要彻底信任本文内容；另外本文会有一小部分纠正之前一篇文章对于intern使用方法的错误，本文会在其中说明使用错误的缘由，大体文章内容有如下几个部分：

一、JVM虚拟内存组成及操做系统地址表

二、新生成对象在HeapSize是如何变化的

三、虚拟机如何定义回收算法

四、JVM占用的空间除HeapSize还会占用什么，OutOfMemory种类！

五、纠正错误：intern的使用上的错误

好，如今开始话题吧：

一、JVM虚拟内存组成及操做系统地址表

1.1.虚拟地址大体概念：在OS层面通常是由逻辑地址映射到线性地址，若是线性地址管理，若是启动了分页，那么线性地址就会转换到相应的物理地址上，不然就直接认为是物理地址；程序设计中所用到的地址单元就是逻辑单元，如在C语言中的&表示指定的地址就是逻辑地址；而物理地址也并不是咱们所认为的RAM，还应该包括网卡、显存、SWAP等相关内容，也就是由OS所管理全部能够经过顶层逻辑单元映射到的目标地点，不过绝大部分状况下只须要考虑RAM便可，尤为是在服务器上；JVM的虚拟内存地址和操做系统的虚拟内存地址不是一个概念，操做系统的虚拟内存地址至关于在磁盘上划分的一个SWAP交换区，用于内存，内存与之作page out和page in的操做，这种用于物理内存自己不够，而地址空间够用的状况，一旦程序出现page out这些状况的时候，程序将会变得很是缓慢，而JVM的虚拟内存是在有效的空间内分配一个连续的线性地址空间，由于JVM想要本身管理内存，分配的堆内存都是在本身的heapSize内部，由于它要实现一些脱离于存储器自己对非连续堆处理的管理而致使的复杂性，也就是JVM去初始化的时候就会加载一块很大的内存单元，而后内部的操做都是内部本身完成的。

1.2.内存分配：通常C语言分配内存是初始化将相应的基本内容和代码段进行加载，可是不会加载运行时候的堆栈内存分配，也就是在运行到某个具体的函数时经过malloc、callloc、realloc等方方申请的区域，这些区域必须从操做系统中从新来分配，使用完成后必须进行free，C++中必须使用delete方法来释放，你们发现没有，OS的堆在内存不断申请和释放的过程当中，必然会产生许多的内存碎片，从而致使你在申请一块大内存的时候，须要进行逻辑链接，致使在申请的速度减少，固然LINUX采用了将内存块划分为多个不一样大小的板块，来较好的处理这个问题，不过片断仍是存在的，不过这种思想的确是很好的，而JVM是如何完成碎片的处理的呢，后面章节会说到；JVM在初始化的时候就会向OS申请一块大内存，JVM要求这块内存在地址空间上是连续的（物理上未必连续），让全部的程序在这个内部区分配，由本身来管理，因此它内部至关于作了一个小的OS对内存的管理，因此JVM是想让java程序员不用关心在哪个平台上写代码，可是你必定要关心java怎么管理内存的；

线性地址随着实际物理内存的增长，将会致使页表很是大，甚至于致使多层页表，如内存达到96G这一类，那么这样管理起来将会很是麻烦（正常状况下一个页只有4K，能够本身算一下须要多少个管理地址来指向这个4K，这个管理地址太大的时候，又须要其余的管理地址来管理这个地址，就会致使多层地址，可能到最后，一个大内存有40%都是用于管理内存的，真正使用的可想而知），因此在LINUX高版本中对于内存寻址方面作了改进，就是支持大页面来支持（实际上是经过一个套件完成的，并不是OS自己），如一个页的大小为1M这样的，可是有一些风险在里面，它要求大页面内存要么放得下你的内存，可是你不能将你的进程一部分放在大页面内存中，一部分放在OS管理的小页面内存中，也就是说要么这块放得下，要么就放在其余地方，可能会致使两边正好都差那么一点点的问题，在OS这边可使用SWAP，可是系统会很慢，并且SWAP不少的状况下确定会宕机掉。

1.3.内存分配状态：一个大的进程若是初始化须要分配一块大的内存空间，内存空间通常会经历两个状态的转换过程，首先内存必须是free状态才能够被分配，若是的确是该状态而且空间是够用的，那么它首先会占用那么大一个坑，在java的heapSize中，就是-Xmx参数指定的，也就是JVM虚拟机最大的内存空间（注意这里-Xmx并无包含PermSize的空间），这个坑是不容许其它进程所占用的，内存的状态为：reserved的状态，当须要使用的空间时，内存将会被commited状态，在JVM初始化时也就是-Xms状态的内存空间，处于这个状态的内存若是发现不够使用（物理内存），此时就会发生swap区域，程序将会变得很是缓慢，可是不会形成宕机，而不少时候在这个时候定位不出缘由，因此咱们为了让物理内存不够用的现象暴露出来能够被发现，至于能够定位不是程序代码的问题，咱们就直接将swap内存禁用掉；有个问题就是既然被reserved的内存就不能被其余进程所占用，为何要在这两个状态之间来回倒腾呢？这不是多一个开销吗？JVM在来回倒腾的过程当中会致使每一个区域的容量发生相应的变化，必然致使的是FullGC的过程，那么JVM通常在服务器端如何设置呢？文章后面逐步细化说明。

1.4.JVM内存组织：关于JVM内存组织方面，前面在讲述Java垃圾回收的时候已经说起到了，可是讲得不太细，有些部分可能算是有错误的，因此这里根据上述操做系统知识以及官方部分资料继续深刻，不敢说彻底正确，不过至少比之前要更加深刻得多，首先来看下ORACLE官方给出来的一个JVM内存单元的组织图形：

其实我看过不少次这个图看得很晕，由于之前不了内存分配中commited与reserved的区别，以致于我当时认为这副图是说java的HeapSize是由N多个部分组成的，而且还包含HeapSize的，其实在通过不少资料查阅后，尤为是看到一些监控工具后，才知道看官方资料也有误区，呵呵，经过简化，我本身画的这副图但愿可以帮助你们理解JVM的大体的内存划分（这里仅仅说起JVM本身的内存，也就是HeapSize和PermSize的部分，其他的文章后面说明），这里仅仅将上面的图形立起来画了，当时看起来要方便理解得不少（我的感受）：

也就是说，你首先须要将JVM的两个大板块分开，一个是HeapSize，也就是上图左侧的部分，右边部分为PermSize的尺寸，HeapSize也划分为大区域为Young和Old区域，Young区域内部划分为三个部分，一个是Eden和两个一样尺寸大小的survivor区域，注意到的人会发现为何每一个区域内部还有一个virtual区域，这就是咱们上面说的没有通过commited当时已经占用了地址列表，它不能被其余进程所占用，当时操做系统通常的提示会认为这是块剩余空间，可是其实是只能被本身使用的，这部分上面已经说起，至于为何咱们后面来解释，这里再提出一些问题，就是为何JVM要提出这么多区域划分来管理呢?若是一个区域能够管理为何还要搞得那么麻烦呢？这么多区域有什么用处，咱们在第二章对象的分配中将详细说明这部份内容。

二、新生成对象在HeapSize是如何变化的

2.1.java新建立对象的方法有哪些：首先学习过java的人可能没有人不知道new 这个关键字，也就是新建立一个对象的关键字，当发生new操做时，jvm为你作了什么？咱们先把这个问题放下，对于jvm初始化加载专门处理，这里先说除了new以外还有什么方式，就是经过java.lang.Class.forName进行动态状态后，获取一个新的实例，固然方法有重载，也经过经过ClassLoader进行动态状态，什么是动态装载？为何有了new还要有动态装载？而jvm初始化作了什么？动态装载和new的区别是什么？这也是咱们下面要讨论的问题，也是PermSize中内容的一大块部分。

2.2.jvm初始化须要作什么？Jvm在向OS请求了一块地址列表后，而后就须要初始化了，初始化要作什么呢？jvm启动至关于一个进程，固然它能够再启动子进程，这里我咱们只考虑单个进程，进程启动必然须要初始化一些内容，C语言或者C++它会将相应的全局变量以及代码段等内容在内存中进行编译为相应的指令集；而jvm作了什么呢？jvm它也须要作一些操做；首先每个进程都必须最少一个引导进程，也就是咱们说的main，经过引导进程所关联，以及关联的关联（也就是import），jvm会将这些关联关系的内容造成一个大的jvm网状结构用于关系于class之间并保证每个class有一份本身的私有池，他们放在哪里，他们就是放在PermSize，也就是不少中文翻译中的永久代，每个Class都有本身独立的私有池去管理自身的结构，对一个java程序源文件，编写的是对于程序的描述信息，生成class也就是描述信息的byte格式（在这个过程当中会自动完成一些简单逻辑合并工做），byte格式是字节码格式，也就是按照每8个bit位组成的计算机基本格式，只要字符集统一，则为每个操做系统所认知的格式，JVM须要作的是将这些统一认知的格式信息翻译为对应操做系统的指令或硬件指令，因此JVM真正的意义就是为每个操做系统编写了一个统一的JRE，即：java运行时环境，而编译环境是全部系统均可以使用的；初始化将class的定义加载到内存中会进行相应的转换和压缩，总之会造成原有对类型描述和执行顺序，而不会出现混乱，但并非对应的操做系统指令（对应的操做系统指令是运行时知道的），如描述类型、做用域、访问权限等等内容，这部分空间大小决定于class的多少，也就是你的工程的大小，PermSize还包含了其余的内容，而且只是在通常状况下不会发生GC，可是有些时候仍是会发生GC的，在后面继续说明；这个加载完成后，他们在池中天然有本身的内存首地址，要寻找他必然要有对应列表，列表的基础确定是属于符号向量了，也就是基于名称的一个符号向量，那么当发生new时，它会在符号向量中寻找对应的class，找到后将符号地址转换为对应的class地址，而且这个内容只会被转载一次，之后能够直接被利用，从中找到了class的定义，在堆中分配内存时将其定义部分的某些组织单元放置与对象的头部，这些代码段对于对象来讲是彼此独立，就像你在方法体前面增长synchronize关键字，对于非静态方法来讲，不一样的对象这个关键字是相互不会影响的，也就是说，若是多个线程调用的对象不是同一个，仅仅在方法（非静态方法）体上面增长synchronized这对于多线程同步是无效的（更多关于多线程的知识，如关锁方面的Lock、Atomic等方面的知识不是本文的内容，这里再也不展开讨论）；注意，这里尚未谈到申请对象以及动态装载，动态装载的class通常是不会JVM初始化的时候转入Perm的，而是运行时动态装载进去的，就像JDBC驱动同样，你们几乎都用动态装载来实现动态加载不一样数据库链接的目的；也就是咱们上一节提出的问题，动态装载作什么？它负责的是运行时装载一些类的定义，而不是初始化，固然，当你经过全名去加载的时候，他们会从符号向量中寻找这个类是否已经加载，若是已经加载则直接使用，不然从相应的包中获取这个class定义，而后装载起来，装载的单位也是以class为单位，并非以jar包为单位，这里请你们若是不要滥用动态加载，一个是形成Perm的不稳定，另外一个是它的效率确定没有new高，由于它须要先去经过符号向量寻找是否存在，不存在再加载，而后再经过newInstance实例化一个或多个实例，固然在某些特殊的时候，利用它能够为你的程序带来极高的灵活性。

2.2.内存申请时的指针与实例：内存申请时上一节已经说到地址空间的和符号引用获得对应数据结构的方法，这里再也不说起，这里就将对象做为总体，在堆中；在JVM的初衷中，它但愿新申请的内存是连续的，虽然堆的定义是让内存是随机分配的，可是对于整个JVM来讲，它但愿分配的内存是较为连续的，也就是按照较为条带化的方式进行分配，好处有好几个，一个是这样很是的简单，通过精简后的状况目前一个new翻译为机器码只须要10条左右的指令码，近乎与C语言，因此在高版本的jdk中，new的开销再也不是java虚拟机慢的一个缘由，你们也没有必要去尽可能减小new，可是也不要滥用，业绩虽乱定义没必要要的对象；其次，另外一个好处，当内存较为连续后，内存在分配上就没有相似的大量碎片的问题，形成运行一段时间后，大量碎片，当须要申请一个大内存的时候，须要寻找很是多的地方才能将其逻辑上组成，而致使分配空间上没必要要的浪费；而一个简单内存分配Stringa =new String("abc");，这样一条代码，会作什么动做呢？a至关因而对象的一个指针同样的东西，这个空间的大小为一个long的长度，也就是能够支持到能够想象的任何内存大小，它并非存放在heapSize中的，而是放在stack中的，由OS来调度管理，也就是当a的做用区域完成，这个指针将会断开，java中的String再也不是C或者C++中的一个指针指向的一个字符数组，而是一个被包装后的对象，也就是java为何说本身都是对象，由于它把原生态的内容进行了包装，让程序编写更加简单；这里顺便说起一下：在较早期的jdk中，jvm并非由一个指针直接指向分配堆中的首地址，而是先有一个handle空间，这个空间存放了开始说的一些对象的定义和结构信息，也就是找到该位置，而后由该位置转换到对应的对象上，可是那个时候的对象头部信息就没有如今的那么全，也就是之前是将一部分handle内容放置在独立的空间上，如今的jdk已经没有那样的了。

2.3.内存分配后放在哪里，如何移动？

终于回到上面的话题，内存分配后，在堆中的什么位置？就是咱们上面说的heapSize中的Young区域的Eden区域中，也就是new的对象绝大部分会放在这里（排除一种很是大的对象的特殊状况），在java设计的看来有一个特别有意思的地方，就是它在新生成的对象中它认为你绝大部分对象都是应该须要被销毁掉的，就像在作java WEB应用上同样，一个列表请求过来，可能请求的内容有2K的内容，请求完成后，这个内容通常说来天然就不须要了，也就是在他原始的考虑下它没有考虑你本身在应用级别去作page cache的操做；好，那么当内存不够的时候，这里指被commited的空间不够的状况下，此时java就会作一个动做，就是会对Young空间进行回收，因为新生成的对象，java认为这块空间不会很大，并且绝大部分应该是被干掉的内容，因此不少时候java会采用单线程的复制算法（固然你也能够设置为多线程），关于算法的核心在第三章中会说到，这里总之先理解找到了活着的对象，将其拷贝到其中一个survivor区域中，当下一次作操做时，就会将Eden中活着的以及前一个surivor活着的一块儿拷贝到另外一个survivor中，这就是为何要设置两个survivor区域，而拷贝后，Eden区域为空、另外一个survivor也为空，能够彻底直接总体清除掉，因此很是快速，而拷贝的目标也会被连续化，新生成的对象又从Eden的初始位置开始分配空间。

当对象每次（活着）被拷贝到一个survivor时，Java虚拟机就会记录下来对象被移动的次数，当次数达到必定的程度，也就是官方文档所说的足够老的状况，这块内存就认为它不太容易被注销掉，此时就会被移动到第二个区域Tenured区域，这个次数也能够由本身来控制。

另外在通常默认的状况下当回收后的内存仍然占用实际目前commited内存的70%以上，那么此时虚拟机将会开始扩展这些内存，而当回收后的内存小于40%后，虚拟机将会下降这部份内存，可是其余线程仍然不能使用（固然这个参数也是可配置的，在文章最后有说明），这样收缩和扩展必然致使一些问题，可是java的初衷是想让你再没有使用这块地址表的时候，回收内存的大小会小一些，由于young区域的通常是使用单线程的回收方式，这个时间段是会被暂停的，因此它认为内存使用较少的时候回收就内存的速度应该加快；可是，和实际相反的是，咱们正好须要的是内存使用较大的时候，才但愿加快回收的速度，内存使用小的时候，回收都是无所谓的；因此咱们在不少时候建议将-Xms和-Xmx设置成同样的大小，不用这么来回倒腾。

在说明下，如下三种状况对象会被晋升到old区域：

一、在eden和survivor中能够来回被minor gc屡次，这个次数超过了-XX:MaxTenuringThreshold

二、在发生minor gc时，发现to survivor没法放下这些对象，就会进入old。

三、在新申请对象，大于eden区域的一半大小时直接进入old，也能够专门设置参数-XX:PretenureSizeThreshold这个参数指定当超过这个值就直接进入old。

当上面的对象被移动到了Tenured区域，这个区域通常很是大，占用了HeapSize的绝大部分空间，此时若它发生一次内存回收，就不能像刚才那样来回拷贝了，那样代价太大，并且这个区域能够说是经得起考验的对象才会被移动过来，在几率上是不容易被销毁掉的对象才会被移动过来；那么，咱们很此时想到的就是反过来计算，也就是找到须要销毁的对象，将其销毁，关于算法也是下面第三章要说的内容，总之对象会在这里存放着。

为何java不论在Young中的区域会来回倒腾，而在Tenured区域也会不断去作压缩，就是咱们前面说的，它但愿内存相对较为连续而作的；java在Yong的区域，它认为能够剩下的内容不会不少，因此拷贝的代价并不大，因此它认为来回拷贝是一种合适的方法，而Tenured区域它采用了清除后，必定次数后进行压缩的方式，固然这个次数你能够本身去设置，在文章的最后是有参数的；而它没有采用相似操做系统同样的按照板块大小等一系列算法来完成，这也是我比较纳闷的事情，不过整体说来这种算法仍是可行的；但愿在划分区域一些策略上能有更大的灵活性，这样能够在更多的应用中发挥得更加灵活，这样就更好了；比较困惑的就是这样的架构本身若是作频繁度不高不低的page cache，性能很差估量，也许比不作cache更低，这个要根据具体状况而定了。

2.3.Perm通常还会存放什么内容？Perm除了存放上面的Class定义外，还通常会存放的内容有静态代码段、final static类型的类变量、String常量以及String被intern后的内容，也是最后一章中所要说起之前我本身写错的内容；如何应对好常量池，以及常量池是否会被GC，也是咱们所须要说明的内容；关于Perm永久代中存放的内容，应当如何配置以致于它能够去回收，在文章的最后有相应的说明，请自行查阅；不过对于Perm的大小，通常仍是不建议去作GC的，也就是合理的去使用Perm，在程序运行中占用Perm最多的就是String常量，尤为是若是大量使用intern的时候，就会形成大量Perm膨胀，也是最后一部分须要说明的内容，不过intern也并不是一无可取，由于你能够这样说：若是它没有用处的话，java没有必要再把String的常量放在单独的一个地方，它有不少好处，只要在适当的时候利用好常量池这个区域在必要的时候能够提升性能，具体在最后一章有所讲解。

三、虚拟机如何定义回收算法

3.1.首先虚拟的回收算法会分红两个部分，一个部分是对象的查找算法，一个是真正如何回收的方法。通常对于查找有如下两种：

a)引用计数：原本在本文中我不想说起引用计数，由于这是最原始也是最垃圾的算法，也是较低版本jdk慢得出奇的缘由，可是为了说明后面的问题不得不简单说明一下，引用计数就是经过java虚拟机专门为每一个对象记录它被指针指向的个数，当发生指针指向它或者被赋值，计数器将会被加1，而但指向它的指针=null或者脱离了做用区域，jvm就会将相应的计数器减小1，这样简单，可是慢死了，不只仅操做上出奇的慢，由于要作一个简单的赋值操做要到多个地方去找一大堆东西；还有一个就会引发很难检测到的内存泄露，那就是当两个或者多个对象存在循环交叉引用的时候，此时他们的引用计数将永远不会等于0（如使用双向链表或使用复杂的集合类后，相互之间的引用），也就是垃圾收集器将永远不会认为这是垃圾（固然要用复杂的算法能够解决，可是这个算法的确很复杂，可能垃圾回收会更加慢），最后就是这个垃圾回收方式必然致使内存的遍历操做过程。引用计数的示意图以下图所示：

b)引用树遍历：实际上是一个图，只是有根而已，它沿着对象的根句柄向下查找到活着的节点，并标记下来，其他没有被标记的节点就是死掉的节点，这些对象就是能够被回收的，或者说活着的节点就是能够被拷贝走的，具体要看所在heapSize中的区域以及算法，它的大体示意图以下图所示(对象：B、G、D、J、K、L、F都是垃圾对象，虽然他们也有相互指向，可是不是被根节点能遍历到的，注意这里是指针是单向的)：

3.2.内存回收：上面的方法咱们能够找到内存能够被使用的，或者说那些内存是能够回收，更多的时候咱们确定愿意作更少的事情达到一样的目的，咱们会根据通常的状况设置不一样的算法来让系统的性能达到较好的程度，首先来了解下内存回收的算法或者它的经历有哪些？

a):标记清除算法，这算是比较原始的算法，也就是经过上面的查找标记后，咱们对没有标记的对象进行空间释放的过程，这个算法虽然很原始，可是是后来全部算法的基础，好处的简单，缺陷是形成和其余语言同样的内存碎片，要经过更加复杂的算法来解决这些碎片；另外一缺陷就是它这个过程若是用于较大的内存将会致使长时间的对外服务中止（固然这个中止也不是传说中那么长，只是相对计算机来讲比较长，至于多长是还和jdk的版本以及厂商有关系，BEA曾经在1G的JVM下面测试，有300M空间属于可用空间，据测试结果为30ms的中止服务时间，我想这个时间应该能够接受，不过它有本身的测试场景，不能彻底说明问题，而通常状况下在单线程引用下，常规的回收起码会比这个时间要长好几倍甚至于10倍以上）。

b)：标记清楚压缩，这个算法是也是较为原始的，它的出现是为了解决上面一种算法中不能压缩空间的问题，可是并不是取代，由于它致使的另外一个问题就是更长时间的服务中止，由于压缩就是空间拷贝到一个较为连续的地方，而并不是对数据自己进行压缩，因此不少时候他们是配合使用的，如多少次清除后进行一次压缩。

c)复制回收：也就是在jvm发展的过程当中出现的算法，如今基本都只能看到一些思想影子在里面，可是没有这个方式，也就是将其划分为2个相同的大小，而后将活着的节点来回拷贝，这样形成的内存浪费的很是大的，不只仅是一半的浪费问题，并且每次拷贝的开销也是很是大的，由于都是涉及到整个jvm活着节点的拷贝过程。

d)增量回收：这算是现代垃圾回收的一个前身，它作的事情就是为了解决复制回收算法中的一个问题，就是每次复制形成的空间开销很是大的问题，此时它将内存中切分为逐个板块，这些板块，每一个内部使用了复制算法，也就是并无解决空间浪费的问题，回收的过程当中没有进行细化，虽然回收速度较快速，并且只会形成局部的中止服务，可是对于不一样板块大小、不一样生命周期的对象仍是没有划分开。

e）分代收集器：分代收集器是增量收集的另外一个化身，或者说延续吧，它将板块按照生命周期划分为上面所说的板块，每个板块能够采用不一样的算法进行回收，这也是和增量回收最大的区别，此时可让jvm的回收达到更好的效果，不过因为jvm按照生命周期划分后都是指定板块的，因此根据内存大小划分自定义板块是不可能的，至少如今好像尚未，因此在回收过程当中若是内存大了回收起来同样很吃力，尤为是对Old区域的回收，因此并发回收不得不出现了。

f）并发回收：所谓并发回收是指外部在访问的同时，java回收器依然在作着回收工做，原早我认为并发回收是不可能的，由于你须要知道内存是须要回收的，就不能让内存继续的被申请和释放，可是SUN的人仍是比较天才的，仍是有办法尽可能让他并发去作的；并发回收器其实也会暂停，可是时间很是短，它并不会在从开始回收寻找、标记、清楚、压缩或拷贝等方式过程彻底暂停服务，它发现有几个时间比较长，一个就是标记，由于这个回收通常面对的是老年代，这个区域通常很大，而通常来讲绝大部分对象应该是活着的，因此标记时间很长，还有一个时间是压缩，可是压缩并不必定非要每一次作完GC都去压缩的，而拷贝呢通常不会用在老年代，因此暂时不考虑；因此他们想出来的办法就是：第一次短暂停机是将全部对象的根指针找到，这个很是容易找到，并且很是快速，找到后，此时GC开始从这些根节点标记活着的节点（这里能够采用并行），而后待标记完成后，此时可能有新的 内存申请以及被抛弃（java自己没有内存释放这一律念），此时JVM会记录下这个过程当中的增量信息，而对于老年代来讲，必需要通过屡次在survivor倒腾后才会进入老年代，因此它在这段时间增量通常来讲会很是少，并且它被释放的几率前面也说并不大（JVM若是不是彻底作Cache，本身作pageCache并且发生几率不大不小的pageout和pagein是不适合的）；JVM根据这些增量信息快速标记出内部的节点，也是很是快速的，就能够开始回收了，因为须要杀掉的节点并很少，因此这个过程也很是快，压缩在必定时间后会专门作一次操做，有关暂停时间在Hotspot版本，也就是SUN的jdk中都是能够配置的，当在指定时间范围内没法回收时，JVM将会对相应尺寸进行调整，若是你不想让它调整，在设置各个区域的大小时，就使用定量，而不要使用比例来控制；当采用并发回收算法的时候，通常对于老年代区域，不会等待内存小于10%左右的时候才会发起回收，由于并发回收是容许在回收的时候被分配，那样就有可能来不及了，因此并发回收的时候，JVM可能会在68%左右的时候就开始启动对老年代GC了。

d）并行回收：并行回收指利用多个CPU对JVM进行并行垃圾回收的过程，并行度都是能够设置的，能够分别对年轻代和老年代配置是否使用并行回收。

好了，回收算法就说到这里，那么如何利用好回收算法，在看了上面的介绍后，是否对JVM有了一个大体的了解，具体细节，能够慢慢实践，在文章最后给出一些经常使用的java虚拟机内存设置参数的说明，不过并不权威，须要根据实际状况而定才能够。

下面说下java虚拟机除了消耗基本内存外还会消耗什么内存？

四、JVM占用的空间除HeapSize还会占用什么？

通常来讲，对于不少学了好几年，甚至于不少年java人来讲，一旦看到OutOfMemeory（简称OOM），就认为HeapSize不够，而后疯狂的增长-Xmx的值，可是HeapSize只是其中一个部分，当你去作一个实验，也就是java启动时直接在程序中疯狂的new 一些线程出来，直到内存溢出，当-Xms -Xmx设置得越大的时候，获得的线程个数会越少，为何呢？由于OOM并非HeapSize不够而致使的，而由不少种状况。

首先看下操做系统如何划份内存给应用系统，其实在Win 3二、Linux 32的系统中，地址总线为32位的理论上应该能够支持4G内存空间，可是当你在Win 32上设置初始化内存若是达到2G，就会报错，说这个块空间无法作，首先默认的Win32系统，会按照50%比例给予给Kernel使用，而另外一部分给应用内存，也就是说操做系统内核部分不管是否使用，这一半是不会给你的，而还有2G呢，它在系统扩展的部分，也就是并不是Kernel的部分，有不少静态区域和字典表的内容，因此要划分一个连续的2G内存给JVM在Win 32上是不可能的，Win 32提出了一种Win 32 3G模式，貌似能够划分3G空间，其实它只是将内核部分缩小也就是管理部分缩小，也就是将一部分划分到外部来使用，并且Win 32习惯在内存2G的位置作一些手脚，让你分配连续2G没有可能性，通常来讲在Win 32平台上，在物理内存足够的状况下给JVM划分的空间通常是1.4~1.5G左右，具体数据没有测试过；而Linux 32相似于Win 32 3G模式，可是它仍是通常状况下分布不凌乱的状况下，通常能够给JVM划分到2G的大小。Linux 32 Hugemem是一个扩展版本，能够划分更大的空间，可是须要付出一些其余的代价，理论上能够支持到4G给应用，也就是Kenel是独立的；Solaris x86-32和AIX 32等系统，也相似于Linux 32平台同样。

为何还要预留一些空间出来呢？这些空间给谁？

当你申请一个线程的时候，它的除了线程内部对象的开销外，线程自己的开销，是须要OS来调度完成，通常来讲，会在OS的线程与虚拟机内部有都有一个一一对应的，可是会根据操做系统不一样有所变化，有些可能只有一个，总之heapSize外的那部分空间是跑不掉的，它放在哪里呢？就是放在Stack中的，因此上文中的-Xss就是设置这个的，在jdk 1.5之后，每一个线程的大小被默认设置为1M的stack开销，咱们习惯将这个开销下降。

好了知道了指针、线程是在heapSize外部的，还有什么呢？

当你本身使用native方法，也就是JNI的时候，调用本地其余语言，如C、C++在程序中使用了malloc等相似方法开辟的内存，都不是在heapSize中的，而是在本地OS所掌控的，另外这部分空间若是没有相应的释放命令，就须要在对应finalize方法内部调用其余的native方法来完成对相应对象的释放，不然这部分将成为OS级别的内存泄露，直到JVM进程重启或者宕机为止（操做系统会记录下进程和相应线程和堆内存的关联关系，可是进程再没有释放前，OS也是不会回收这部份内存的）。

另外在使用JavaNIO以及JDBC、流等系列操做时，当造成与终端交互时，会在另外一个位置造成一个内存区域，这些内存区域都不在HeapSize中。

因此常见的OOM现象有如下几种：

一、heapSize溢出，这个须要设置Java虚拟机的内存状况

二、PermSize溢出，须要设置Perm相关参数以及检查内存中的常量状况。

三、OS地址空间不够，也就是没有那么多内存分配，这个通常是启动时报错。

四、Swap空间频繁交互，进程直接被crash掉，在不一样操做系统中会体现不一样的状况。

五、native Thread溢出，注意线程Stack的大小，以及自己操做系统的限制。

六、DirectByteBuffer溢出，这一类通常是在作一些NIO操做的时候，或在某种状况下使用ByteBuffer，在分配内存时使用了allocateDirect以及使用一些框架间接调用了相似方法，致使直接内存的分配（如mina中使用IoByte去调用，当参数设置为true的时候就分配为直接内存，所谓直接内存就是又OS定义的内存，而不须要从程序间接拷贝一次再输出的过程，提升性能，可是若是没有手动回收是回收不掉的），致使的Buffer问题，如输出大量的内容，输入大量的内容，此时须要尽可能去尝试限制它的大小。

使用很是多的工具区检测Java的内存如：jstat（只能看HeapSize和PermSize）、jmap（很细的东西）、jps（java的ps -ef呵呵）、jdb（这个不是监控工具哈，这个是debug工具）、jprofile（图形支持，可是能够远程链接）等等；jconsole（能够看到heapsize、permsize+native mem size（这这里叫作：non-heapsize）等等的使用的趋势图）、visualvm(极为推荐的东西，图形化查看，你能够查看到内存单元分配、交换、回收、移动等等整个过程，很是清晰展示jvm的全局资源)、另外pmap能够展示很是清晰的资料，能够精确到某一个java进程内部的每个细节，并且能够看到heapsize只是其中很小一部分（在solaris操做系统上看得最齐全，LINUX下有些进程可能看不太懂）；也能够在/proc/进程号/maps中查看（这里能够看到内存地址单元的起始地址，包含了reserved的地址范围和commited的地址范围），全局资源使用操做系统top命令和free命令看；IBM有一个GCMV免费下载工具也很好；Win32有一个WMMap工具都是很好的工具

使用相应的工具观察相应的内容，当观察到内存的使用从无到有，上升，而后处于一个平稳趋势，那么这个JVM应该是较为稳定的；若是发现它通过一段平滑期后，又出现飙升，这个必然是有问题的，至于什么问题，根据前面的学下和实际状况咱们能够去分析；当它开始后，平滑过程，出现缓慢上升的过程，可是始终会上升到极点，那么一个是须要知道物理内存时候可用，另外一个就是少许的内存泄露（JVM现代也有内存泄露，只是它的内存泄露并不是C、C++中的内存泄露）。

五、纠正错误：intern的使用上的错误

最后一章节，我本身纠正一下我本身的错误，之前的文章中，也就是关于intern的使用，最近对他作了一些深刻研究，由于之前也是和不少同窗同样，听到别人推荐什么就疯狂的使用，知道点原理也是点大概，没有深刻研究内部的内容。

我曾经在文章中说到任何系统最多使用的数据类型必然是String，无论作什么，因此在String的处理上颇有研究，推荐使用java的朋友在大量使用对比的时候不要用equals，而推荐使用intern，可是我最近发现我错了，我这里给你们道歉，由于可能会误导不少朋友；下面说明下这个东西为何？

首先我开始本身怀疑本身的时候是想说，若是intern能够作到高效，那么equals是否是在String中就没有存在的必要了呢，当时对于我理解仅仅为常量池的一个地址对比，比如是两个数字的compare，仅仅须要CPU的单个指令便可完成；因而我开始作了两个实验，一个是最原始，最初级的方法采用单线程循环1000000次调用equals与intern等值对比，而且采用了不一样长度的字符串去作比较，发现equals居然比intern要快，并且随着字符串长度的增长，equals会明显快与intern，而后使用多线程测试也是获得同样的效果，我首先很不敢相信本身坚持的理论被完全和谐了，后来冷静下来必须须要面对，经过不少权威资料的阅读，我发现我对JVM常量池的理解还只是一点点皮毛而已，因此我作了更加深刻的研究。

原来intern方法被调用时是在Perm中的String私有化常量池中寻找相应的内容，而寻找虽然能够经过hash定位到某些较小的链表中，可是仍是须要在链表中逐个对比，对比的方法仍然是equals，也就是抛开hash的开销，intern最少要与里面的0到多个对象进行equals操做，并且若是不存在，还要在常量池开辟一块空间来记录，若是存在则返回地址，也就是常量池保证每一个String常量是惟一的，这个开销固然大了，并且若是使用在业务代码中将会致使Perm区域的不断增长；

因而，我又反过来想了：既然equals比他效率高，为啥还要用intern呢？并且equals的那个算法对于长字符串逐个字符对比的过程我实在是难以入目；并且也实在是以为不甘心本身的理论就这么容易被和谐掉，由于本身已经在很多程序中这样用过，这样我岂不是犯下大错了，由于本身参与过的项目的确太多了，并且有相似的代码我写入了框架中，最终发现我可能错了一半，也就是历史上的记录可能我有一半相似的代码是错误的；为何呢？intern仍是有用的，我先作了一个测试，那就是，用一个已经intern好的对象，让他与一个常量作等值，循环次数和上面同样，结果我预料的结果发生了，那就是比equals快出了N多倍数，随着长度的增长，会体现出更加明显的优点，由于intern对比的始终是地址，和长度无关，因而我想到了如何使用它，就是在程序中返回经过字符串相似于数字同样的类型断定时，如：作一个sqlparser的时候，常常根据数据类型作不一样的动做，这样若是用equals会在每次循环时付出不少开销，尤为是不少数据库的类型很是多，最坏的是从上到下每一个字符串匹配一次，固然长度不等开销很小，长度相等开销就大了；intern我就将这些schema信息预先intern掉，也就是他们已经指向了常量池，当再真正匹配时，就不须要用intern了，而是直接匹配，也就是将这个开销放在初始化的过程当中，运行时咱们不去增长它的开销。

因此，我的是犯下一个错误，而且之前还很张扬的处处宣传，呵呵，如今以为有点傻，但愿在看到某些推荐用什么新东西的时候，千万不要在没有研究明白他就去用它，甚至于滥用它，至少要通过一些简单的测试，不过对于现代不少复杂的东西，一些简单的测试已经不足以说明问题，就像Lock与Synchronize的开销同样，若是采用简单的循环的话，你会发现新版本的Lock的开销将会比Synchronized的开销更加大，它适合的是并发，读写的并发，因此真正要弄清楚仍是研究内在。

最后说下，我我的对JVM的指望，JVM作到了不少个板块之间使用不一样的算法，而JVM不但愿程序员去关心内存，可是有些特殊的应用须要JVM提供多的支持，固然有些公司对JVM内核进行了改造来适合特殊的应用，可是咱们更加但愿标准的JVM可以提供更加灵活的内存管理机制，而不只局限于配置，由于配置适中是死的，在不少时候会面临扩展性的限制；如不少时候咱们认为能够断定不少的对象自己就是不会被回收或者根本不容易被回收的，就不用到Young的空间和其余的业务套在一块儿倒腾了；对于常常作page cache的系统，而page cache的命中率不是特别高（95%以上就很高），也不是很低（如80%如下），这个时候，置换到快不慢的，而会致使在老年代的回收的频繁起来，就我我的但愿这些空间都能独立出来，甚至于能够由程序去控制和指定，固然JVM能够自身去默认；尤为是按照一些特殊的对象等级类型或者说对象的大小，这些细节均可以采用一些相应的默认GC手段来完成，也能够人工的指定，固然也在默认状况下能够按照原有的模式进行架构，这样JVM的内存调节的灵活将会更加宽松，使得它能在各种场合下只要使用相对应的手段配置和程序调整都是能够打到目的的。

本文包含大量我的看法，若有不是之处，请你们多多指教！本文到此完结，内容粗而不深刻，细节问题，细节讨论。

常见参数JVM参数配置（java vm Hotspot TM 1.6）：

•-Xms为初始化为HeapSize的空间，即被Commited的尺寸。

•-Xmx为最大的HeapSize空间，有些还没有被Commited，可是已经被进程所Reserved，当如今已经被Commit的空间长期处于(jdk1.1还有一个-mx为包含handler表的空间)。

•-Xmn设置Young的空间大小，此时NewSize和MaxNewSize一致，或者分别设置-XX:NewSize=128m

•-XX:PermSize = 64M及-XX:MaxPermSize= 64M为永久代的初始大小和最大大小。

•-XX:NewRatio= 3为Tenured:Young的初始尺寸比例（设置了大小就再也不设置此值），此时Young占用整个HeapSize的1/4大小。

•-XX:SurvivorRatio= 6：为Eden:Survivor比例大小，此时一个Survivor占用Young的1/8大小，而Eden占用3/4大小。

•-Xss=256k为ThreadStack空间大小，jdk 1.5之后默认是1M，在IBM的jdk中还有-Xoss参数（此时每一个线程占用的stack空间为256K大小）

•-XX:MaxTenuringThreshold=3：通常一个对象在Young通过多少次GC后会被移动到OLD区。

-XX:+UseParNewGC：对Yong区域启用并行回收算法。

•-XX:+UseParallelGC：一种较老的并行回收算法。

•-XX:+UseParallelOldGC：对Tenured区域使用并行回收算法。

•-XX:ParallelGCThread=10：并行的个数，通常和CPU个数相对应。

•-XX:+UseAdaptiveSizepollcy：收集器自动根据实际状况进行一些比例以及回收算法调整。

•-XX:CMSFullGCsBeforeCompaction= 3：多少次GC后会进行压缩碎片

•-XX:+UseCmsFullCompactAtFullCollction：打开老年代压缩

-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled

-XX:+CMSPermGenSweepingEnabled对永久带进行相应的回收，在jdk1.6中不须要数：-XX:+CMSPermGenSweepingEnabled

-XX:MinHeapFreeRatio这是指剩余空间百分比多少时，开始减少commited的内存；

-XX:MaxHeapFreeRatio指剩余空间百分比多少时，开始增长commited的内存，直到-Xmx大小。

-XX:MaxGCPauseMillis指GC最大的暂停时间，当超过这个时间，那么JVM会适当调整内存比例（前提是使用的是基于比例的YONG和设置）。

-XX:+UseConcMarkSweepGC启动并发GC，通常针对Tenured区域。

-XX:+CMSIncrementalMode增量GC，将内存切块，分布在多个局部去GC。

-XX:CMSInitiatingOccupancyFraction在并发GC下，因为一边使用，一遍GC，就不能在不够用的时候GC，默认状况下是在使用了68%的时候进行GC，经过该参数能够调整实际的值。

大体的参数设置就这些，可是GC自己的参数还有不少，尤为是和应用或者和具体硬件结合起来的时候，而BEA和IBM也有本身的JDK，这里有些参数他们支持，有些参数不支持，在某些平台和甚至于硬件上能够支持特殊的参数来控制（如在部分intel系列的多CPU机器上，经过它的NUMA架构，能够设置对应参数支撑，节点和CPU之间能够实现分工负载、常规服务上都是SMP的，而大型机上多半是MPP）；相似于上面的并发GC在通常状况下是不会进行compact压缩的，由于它但愿回收的时间短，可是充满compact的压缩时间必然不是那么短，因此在部分特殊应用下有些使用定宽度的内存尺寸，回收后无论空余内存，由于每一个内存的尺寸都是那么大，这样来处理，固然这样必然会致使不少的内存浪费，可是它的好处是能够没有compact而不存在说要分配的内存分配不到的问题。