JVM内存管理&GC机制 原理资料收集

(整理中。。)

先看一看JVM的内部结构——


如图所示，JVM主要包括两个子系统和两个组件。两个子系统分别是Class loader子系统和Execution engine(执行引擎) 子系统；两个组件分别是Runtime data area (运行时数据区域)组件和Native interface(本地接口)组件。

Class loader子系统的作用：根据给定的全限定名类名(如 java.lang.Object)来装载class文件的内容到 Runtime data area中的method area(方法区域)。Java程序员可以extends java.lang.ClassLoader类来写自己的Class loader。

Execution engine子系统的作用：执行classes中的指令。任何JVM specification实现(JDK)的核心都是Execution engine，不同的JDK例如Sun 的JDK 和IBM的JDK好坏主要就取决于他们各自实现的Execution  engine的好坏。

Native interface组件：与native libraries交互，是其它编程语言交互的接口。当调用native方法的时候，就进入了一个全新的并且不再受虚拟机限制的世界，所以也很容易出现JVM无法控制的native heap OutOfMemory。

Runtime Data Area组件：这就是我们常说的JVM的内存了。它主要分为五个部分——
1、Heap (堆)：一个Java虚拟实例中只存在一个堆空间
2、Method Area(方法区域)：被装载的class的信息存储在Method area的内存中。当虚拟机装载某个类型时，它使用类装载器定位相应的class文件，然后读入这个class文件内容并把它传输到虚拟机中。
3、Java Stack(java的栈)：虚拟机只会直接对Java stack执行两种操作：以帧为单位的压栈或出栈
4、Program Counter(程序计数器)：每一个线程都有它自己的PC寄存器，也是该线程启动时创建的。PC寄存器的内容总是指向下一条将被执行指令的饿地址，这里的地址可以是一个本地指针，也可以是在方法区中相对应于该方法起始指令的偏移量。
5、Native method stack(本地方法栈)：保存native方法进入区域的地址

以上五部分只有Heap 和Method Area是被所有线程的共享使用的；而Java stack, Program counter 和Native method stack是以线程为粒度的，每个线程独自拥有自己的部分。

了解JVM的系统结构，再来看看JVM内存回收问题了——
Sun的JVM Generational Collecting(垃圾回收)原理是这样的：把对象分为年青代(Young)、年老代(Tenured)、持久代(Perm)，对不同生命周期的对象使用不同的算法。(基于对对象生命周期分析)


如上图所示，为Java堆中的各代分布。
1. Young（年轻代）
年轻代分三个区。一个Eden区，两个Survivor区。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制年老区(Tenured。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来 对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。
2. Tenured（年老代）
年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。
3. Perm（持久代）
用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=进行设置。

举个例子：当在程序中生成对象时，正常对象会在年轻代中分配空间，如果是过大的对象也可能会直接在年老代生成（据观测在运行某程序时候每次会生成一个十兆的空间用收发消息，这部分内存就会直接在年老代分配）。年轻代在空间被分配完的时候就会发起内存回收，大部分内存会被回收，一部分幸存的内存会被拷贝至Survivor的from区，经过多次回收以后如果from区内存也分配完毕，就会也发生内存回收然后将剩余的对象拷贝至to区。等到to区也满的时候，就会再次发生内存回收然后把幸存的对象拷贝至年老区。

通常我们说的JVM内存回收总是在指堆内存回收，确实只有堆中的内容是动态申请分配的，所以以上对象的年轻代和年老代都是指的JVM的Heap空间，而持久代则是之前提到的Method Area，不属于Heap。

了解完这些之后，以下的转载一热衷于钻研技术的哥们Richen Wang关于内存管理的一些建议——
1、手动将生成的无用对象，中间对象置为null，加快内存回收。
2、对象池技术 如果生成的对象是可重用的对象，只是其中的属性不同时，可以考虑采用对象池来较少对象的生成。如果有空闲的对象就从对象池中取出使用，没有再生成新的对象，大大提高了对象的复用率。
3、JVM调优 通过配置JVM的参数来提高垃圾回收的速度，如果在没有出现内存泄露且上面两种办法都不能保证内存的回收时，可以考虑采用JVM调优的方式来解决，不过一定要经过实体机的长期测试，因为不同的参数可能引起不同的效果。如-Xnoclassgc参数等。

推荐的两款内存检测工具
1、jconsole  JDK自带的内存监测工具，路径jdk bin目录下jconsole.exe，双击可运行。连接方式有两种，第一种是本地方式如调试时运行的进程可以直接连，第二种是远程方式，可以连接以服务形式启动的进程。远程连接方式是：在目标进程的jvm启动参数中添加-Dcom.sun.management.jmxremote.port=1090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false  1090是监听的端口号具体使用时要进行修改，然后使用IP加端口号连接即可。通过该工具可以监测到当时内存的大小，CPU的使用量以及类的加载，还提供了手动gc的功能。优点是效率高，速度快，在不影响进行运行的情况下监测产品的运行。缺点是无法看到类或者对象之类的具体信息。使用方式很简单点击几下就可以知道功能如何了，确实有不明白之处可以上网查询文档。

2、JProfiler 收费的工具，但是到处都有破解办法。安装好以后按照配置调试的方式配置好一个本地的session即可运行。可以监测当时的内存、CPU、线程等，能具体的列出内存的占用情况，还可以就某个类进行分析。优点很多，缺点太影响速度，而且有的类可能无法被织入方法，例如我使用jprofiler时一直没有备份成功过，总会有一些类的错误。

 

ref:http://soft.zdnet.com.cn/techupdate/2009/1217/1562494.shtml

1）堆

所有通过new创建的对象的内存都在堆中分配，其大小可以通过-Xmx和-Xms来控制。堆被划分为新生代和旧生代，新生代又被进一步划分为Eden和Survivor区，最后Survivor由FromSpace和ToSpace组成，结构图如下所示：

新生代。新建的对象都是用新生代分配内存，Eden空间不足的时候，会把存活的对象转移到Survivor中，新生代大小可以由-Xmn来控制，也可以用-XX:SurvivorRatio来控制Eden和Survivor的比例旧生代。用于存放新生代中经过多次垃圾回收仍然存活的对象

2）栈

每个线程执行每个方法的时候都会在栈中申请一个栈帧，每个栈帧包括局部变量区和操作数栈，用于存放此次方法调用过程中的临时变量、参数和中间结果

3）本地方法栈

用于支持native方法的执行，存储了每个native方法调用的状态

4）方法区

存放了要加载的类信息、静态变量、final类型的常量、属性和方法信息。JVM用持久代（PermanetGeneration）来存放方法区，可通过-XX:PermSize和-XX:MaxPermSize来指定最小值和最大值。介绍完了JVM内存组成结构，下面我们再来看一下JVM垃圾回收机制。

JVM垃圾回收机制

JVM分别对新生代和旧生代采用不同的垃圾回收机制

新生代的GC：

新生代通常存活时间较短，因此基于Copying算法来进行回收，所谓Copying算法就是扫描出存活的对象，并复制到一块新的完全未使用的空间中，对应于新生代，就是在Eden和FromSpace或ToSpace之间copy。新生代采用空闲指针的方式来控制GC触发，指针保持最后一个分配的对象在新生代区间的位置，当有新的对象要分配内存时，用于检查空间是否足够，不够就触发GC。当连续分配对象时，对象会逐渐从eden到 survivor，最后到旧生代，

用javavisualVM来查看，能明显观察到新生代满了后，会把对象转移到旧生代，然后清空继续装载，当旧生代也满了后，就会报outofmemory的异常，如下图所示：

在执行机制上JVM提供了串行GC（SerialGC）、并行回收GC（ParallelScavenge）和并行GC（ParNew）

1）串行GC

在整个扫描和复制过程采用单线程的方式来进行，适用于单CPU、新生代空间较小及对暂停时间要求不是非常高的应用上，是client级别默认的GC方式，可以通过-XX:+UseSerialGC来强制指定

2）并行回收GC

在整个扫描和复制过程采用多线程的方式来进行，适用于多CPU、对暂停时间要求较短的应用上，是server级别默认采用的GC方式，可用-XX:+UseParallelGC来强制指定，用-XX:ParallelGCThreads=4来指定线程数

3）并行GC

与旧生代的并发GC配合使用

旧生代的GC：

旧生代与新生代不同，对象存活的时间比较长，比较稳定，因此采用标记（Mark）算法来进行回收，所谓标记就是扫描出存活的对象，然后再进行回收未被标记的对象，回收后对用空出的空间要么进行合并，要么标记出来便于下次进行分配，总之就是要减少内存碎片带来的效率损耗。在执行机制上JVM提供了串行 GC（SerialMSC）、并行GC（parallelMSC）和并发GC（CMS），具体算法细节还有待进一步深入研究。

以上各种GC机制是需要组合使用的，指定方式由下表所示：

 

ref:

http://blog.163.com/guixl_001/blog/static/4176410420108296361891/

 

作者：Jason S.H.Chen
名词解释：
JVM（Java Virtual Machine）：Java虚拟机，所有的Java程序都在Java虚拟机中运行。
元数据：在本文中指用于描述类和接口定义的数据。

在我做J2EE系统开发的工作生涯中，经常遇到技术人员或客户发出诸如此类的感慨：我的J2EE应用系统处理的数据量不大，系统体积也不大，技术架构也没有问题，我的应用服务器的内存有4G或8G；系统运行起来很慢，还经常出现内存溢出错误。真是无奈！每次遇到这样的情况，我心中都会忍不住窃笑之。

其实他们所遇到这种情况，不是技术架构上的问题，不是系统本身的问题，也不是应用服务器的问题，也可能不是服务器的内存资源真的不足的问题。他们花了很多时间在J2EE应用系统本身上找问题（当然一般情况下，这种做法是对的；当出现问题时，在自身上多找找有什么不足），结果还是解决不了问题。他们却忽略了很重要的一点：J2EE应用系统是运行在J2EE应用服务器上的，而J2EE应用服务器又是运行在JVM（Java Virtual Machine）上的。
其实在生产环境中JVM参数的优化和设置对J2EE应用系统性能有着决定性的作用。本篇我们就来分析JAVA的创建者SUN 公司的JVM的内存管理机制（在现实中绝大多数的应用服务器是运行在SUN公司的JVM上的，当然除了SUN公司的JVM，还有IBM的JVM，Bea的JVM等）；下篇咱们具体讲解怎样优化JVM的参数以达到优化J2EE应用的目的。
咱们先来看JVM的内存管理制吧，JVM的早期版本并没有进行分区管理；这样的后果是JVM进行垃圾回收时，不得不扫描JVM所管理的整片内存，所以搜集垃圾是很耗费资源的事情，也是早期JAVA程序的性能低下的主要原因。随着JVM的发展，JVM引进了分区管理的机制。
采用分区管理机制的JVM将JVM所管理的所有内存资源分为2个大的部分。永久存储区（Permanent Space）和堆空间（The Heap Space）。其中堆空间又分为新生区（Young (New) generation space）和养老区（Tenure (Old) generation space），新生区又分为伊甸园（Eden space），幸存者0区（Survivor 0 space）和幸存者1区（Survivor 1 space）。具体分区如下图：




那JVM他的这些分区各有什么用途，请看下面的解说。
永久存储区（Permanent Space）：永久存储区是JVM的驻留内存，用于存放JDK自身所携带的Class,Interface的元数据，应用服务器允许必须的Class,Interface的元数据和Java程序运行时需要的Class和Interface的元数据。被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭JVM时，释放此区域所控制的内存。

堆空间（The Heap Space）：是JAVA对象生死存亡的地区，JAVA对象的出生，成长，死亡都在这个区域完成。堆空间又分别按JAVA对象的创建和年龄特征分为养老区和新生区。

新生区（Young (New) generation space）：新生区的作用包括JAVA对象的创建和从JAVA对象中筛选出能进入养老区的JAVA对象。

伊甸园（Eden space）：JAVA对空间中的所有对象在此出生，该区的名字因此而得名。也即是说当你的JAVA程序运行时，需要创建新的对象，JVM将在该区为你创建一个指定的对象供程序使用。创建对象的依据即是永久存储区中的元数据。

幸存者0区（Survivor 0 space）和幸存者1区（Survivor1 space）：当伊甸园的控件用完时，程序又需要创建对象；此时JVM的垃圾回收器将对伊甸园区进行垃圾回收，将伊甸园区中的不再被其他对象所引用的对象进行销毁工作。同时将伊甸园中的还有其他对象引用的对象移动到幸存者0区。幸存者0区就是用于存放伊甸园垃圾回收时所幸存下来的JAVA对象。当将伊甸园中的还有其他对象引用的对象移动到幸存者0区时，如果幸存者0区也没有空间来存放这些对象时，JVM的垃圾回收器将对幸存者0区进行垃圾回收处理，将幸存者0区中不在有其他对象引用的JAVA对象进行销毁，将幸存者0区中还有其他对象引用的对象移动到幸存者1区。幸存者1区的作用就是用于存放幸存者0区垃圾回收处理所幸存下来的JAVA对象。

养老区（Tenure (Old) generation space）：用于保存从新生区筛选出来的JAVA对象。
上面我们看了JVM的内存分区管理，现在我们来看JVM的垃圾回收工作是怎样运作的。首先当启动J2EE应用服务器时，JVM随之启动，并将JDK的类和接口，应用服务器运行时需要的类和接口以及J2EE应用的类和接口定义文件也及编译后的Class文件或JAR包中的Class文件装载到JVM的永久存储区。在伊甸园中创建JVM，应用服务器运行时必须的JAVA对象，创建J2EE应用启动时必须创建的JAVA对象；J2EE应用启动完毕，可对外提供服务。
JVM在伊甸园区根据用户的每次请求创建相应的JAVA对象，当伊甸园的空间不足以用来创建新JAVA对象的时候，JVM的垃圾回收器执行对伊甸园区的垃圾回收工作，销毁那些不再被其他对象引用的JAVA对象（如果该对象仅仅被一个没有其他对象引用的对象引用的话，此对象也被归为没有存在的必要，依此类推），并将那些被其他对象所引用的JAVA对象移动到幸存者0区。
如果幸存者0区有足够控件存放则直接放到幸存者0区；如果幸存者0区没有足够空间存放，则JVM的垃圾回收器执行对幸存者0区的垃圾回收工作，销毁那些不再被其他对象引用的JAVA对象（如果该对象仅仅被一个没有其他对象引用的对象引用的话，此对象也被归为没有存在的必要，依此类推），并将那些被其他对象所引用的JAVA对象移动到幸存者1区。
如果幸存者1区有足够控件存放则直接放到幸存者1区；如果幸存者0区没有足够空间存放，则JVM的垃圾回收器执行对幸存者0区的垃圾回收工作，销毁那些不再被其他对象引用的JAVA对象（如果该对象仅仅被一个没有其他对象引用的对象引用的话，此对象也被归为没有存在的必要，依此类推），并将那些被其他对象所引用的JAVA对象移动到养老区。
如果养老区有足够控件存放则直接放到养老区；如果养老区没有足够空间存放，则JVM的垃圾回收器执行对养老区区的垃圾回收工作，销毁那些不再被其他对象引用的JAVA对象（如果该对象仅仅被一个没有其他对象引用的对象引用的话，此对象也被归为没有存在的必要，依此类推），并保留那些被其他对象所引用的JAVA对象。如果到最后养老区，幸存者1区，幸存者0区和伊甸园区都没有空间的话，则JVM会报告“JVM堆空间溢出（java.lang.OutOfMemoryError: Java heap space）”，也即是在堆空间没有空间来创建对象。
这就是JVM的内存分区管理，相比不分区来说；一般情况下，垃圾回收的速度要快很多；因为在没有必要的时候不用扫描整片内存而节省了大量时间。
通常大家还会遇到另外一种内存溢出错误“永久存储区溢出（java.lang.OutOfMemoryError: Java Permanent Space）”。
好，本篇对SUN 的JVM内存管理机制讲解就到此为止，下一篇我们将详细讲解怎样优化SUN 的JVM让我们的J2EE系统运行更快，不出现内存溢出等问题。

 

http://cshbbrain.iteye.com/blog/526356

 

System.GC 算法

• 博客分类：

　   1、 引用计数法(Reference Counting Collector)  

　　引用计数法是唯一没有使用根集的垃圾回收的法，该算法使用引用计数器来区分存活对象和不再使用的对象。一般来说，堆中的每个对象对应一个引用计数器。当每一次创建一个对象并赋给一个变量时，引用计数器置为1。当对象被赋给任意变量时，引用计数器每次加1当对象出了作用域后(该对象丢弃不再使用)，引用计数器减1，一旦引用计数器为0，对象就满足了垃圾收集的条件。  

　　基于引用计数器的垃圾收集器运行较快，不会长时间中断程序执行，适宜地必须 实时运行的程序。但引用计数器增加了程序执行的开销，因为每次对象赋给新的变量，计数器加1，而每次现有对象出了作用域生，计数器减1。  

　　2、tracing算法(Tracing Collector)  

　　tracing算法是为了解决引用计数法的问题而提出，它使用了根集的概念。基于tracing算法的垃圾收集器从根集开始扫描，识别出哪些对象可达，哪些对象不可达，并用某种方式标记可达对象，例如对每个可达对象设置一个或多个位。在扫描识别过程中，基于tracing算法的垃圾收集也称为标记和清除(mark-and-sweep)垃圾收集器.  

　　3、compacting算法(Compacting Collector)  

　　为了解决堆碎片问题，基于tracing的垃圾回收吸收了Compacting算法的思想，在清除的过程中，算法将所有的对象移到堆的一端，堆的另一端就变成了一个相邻的空闲内存区，收集器会对它移动的所有对象的所有引用进行更新，使得这些引用在新的位置能识别原来 的对象。在基于Compacting算法的收集器的实现中，一般增加句柄和句柄表。  

　　4、copying算法(Coping Collector)  

　　该算法的提出是为了克服句柄的开销和解决堆碎片的垃圾回收。它开始时把堆分成 一个对象 面和多个空闲面， 程序从对象面为对象分配空间，当对象满了，基于coping算法的垃圾 收集就从根集中扫描活动对象，并将每个 活动对象复制到空闲面(使得活动对象所占的内存之间没有空闲洞)，这样空闲面变成了对象面，原来的对象面变成了空闲面，程序会在新的对象面中分配内存。  

　　一种典型的基于coping算法的垃圾回收是stop-and-copy算法，它将堆分成对象面和空闲区域面，在对象面与空闲区域面的切换过程中，程序暂停执行。  

　　5、generation算法(Generational Collector)  

　　stop-and-copy垃圾收集器的一个缺陷是收集器必须复制所有的活动对象，这增加了程序等待时间，这是coping算法低效的原因。在程序设计中有这样的规律：多数对象存在的时间比较短，少数的存在时间比较长。因此，generation算法将堆分成两个或多个，每个子堆作为对象的一代(generation)。由于多数对象存在的时间比较短，随着程序丢弃不使用的对象，垃圾收集器将从最年轻的子堆中收集这些对象。在分代式的垃圾收集器运行后，上次运行存活下来的对象移到下一最高代的子堆中，由于老一代的子堆不会经常被回收，因而节省了时间。  

　　6、adaptive算法(Adaptive Collector)  

　　在特定的情况下，一些垃圾收集算法会优于其它算法。基于Adaptive算法的垃圾收集器就是监控当前堆的使用情况，并将选择适当算法的垃圾收集器。  
透视Java垃圾回收  

　　1、命令行参数透视垃圾收集器的运行  

　　2、使用System.gc()可以不管JVM使用的是哪一种垃圾回收的算法，都可以请求Java的垃圾回收。在命令行中有一个参数-verbosegc可以查看Java使用的堆内存的情况，它的格式如下：  

　　java -verbosegc classfile  

　　可以看个例子： class TestGC ...{
  public static void main(String[] args) ...{
    new TestGC();
    System.gc();
    System.runFinalization();
  }
}


　　在这个例子中，一个新的对象被创建，由于它没有使用，所以该对象迅速地变为可达，程序编译后，执行命令： java -verbosegc TestGC 后结果为：  

　　[Full GC 168K->97K(1984K)， 0.0253873 secs]  

　　机器的环境为，Windows 2000 + JDK1.3.1，箭头前后的数据168K和97K分别表示垃圾收集GC前后所有存活对象使用的内存容量，说明有168K-97K=71K的对象容量被回收，括号内的数据1984K为堆内存的总容量，收集所需要的时间是0.0253873秒（这个时间在每次执行的时候会有所不同）。  

http://meng-lin.iteye.com/blog/386835

 

 

JVM的内存管理 Ⅳ

摘要: 　　这是最后一篇有关内存管理的文章，其实内存管理有许多技巧和方式，在这，我给大家介绍一下。　　（1）要尽早的释放无用对象的引用。如果，该对象不用了，你可以把它设置为null。但要注意，如果该对象是某方法的 ...

这是最后一篇有关内存管理的文章，其实内存管理有许多技巧和方式，在这，我给大家介绍一下。 　　（1）要尽早的释放无用对象的引用。如果，该对象不用了，你可以把它设置为null。但要注意，如果该对象是某方法的返回值，千万不要这样处理，否则你从该方法中得到的返回值永远为空，而且这种错误不易被发现，因此这时很难及时抓住、排除NullPointerException异常。 　　（2）尽量少用finalize函数。因为它会加大GC的工作量，因此尽量少用finalize方式回收资源。 　　（3）如果需要使用经常用到的图片，可以使用soft应用类型（也就是转换为软引用类型），它可以尽可能将图片保存在内存中，供程序调用，而不引起OutOfMemory。 　　（4）注意集合数据类型，包括数组、树、图、链表等数据结构，这些数据结构对于GC来说，回收更为复杂。另外，要注意那些全局变量，静态变量，这些对象往往容易引起悬挂对象，造成内存浪费。 　　（5）尽量避免在类的默认构造器中创建、初始化大量的对象，防止在调用其子类的构造器时造成不必要的内存资源浪费。 　　（6）尽量避免强制系统做垃圾内存回收（通过显式调用方法System.gc())，增长系统做垃圾回收的最终时间，降低系统性能。 　　（7）尽量避免显式申请数组空间，当不得不显式申请数组空间时尽量准确的估计出其合理值，以免造成不必要的系统内存开销。 　　（8）尽量在做远程方法调用（RMI）类应用开发时使用瞬间值变量，除非远程调用端需要获取该瞬间值变量的值。 　　（9）尽量在合适的场景下使用对象池技术以提高系统的性能，缩减系统内存开销，但是要注意对象池的尺寸不易过大，及时清除无效对象释放内存资源，综合考虑应用运行环境的内存资源限制，避免过高估计运行环境所提供内存资源的数量。 　　虽然，这些技巧提高不了多少性能，但是，在嵌入式开发，或者要求性能比较高的系统中却很有用。 　　我最近在搞Android ，性能方面要求比较高，所以看看这些，同时也把这些写出来，希望能和大家一起进步。

http://www.189works.com/article-7122-1.html

 

 

JVM内存管理

　　内存溢出就是你要求分配的java虚拟机内存超出了系统能给你的，系统不能满足需求，于是产生溢出。

　　内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问,该块已分配出来的内存也无法再使用，随着服务器内存的不断消耗，而无法使用的内存越来越多，系统也不能再次将它分配给需要的程序，产生泄露。一直下去，程序也逐渐无内存使用，就会溢出。（内存泄露vs内存溢出）

【内存空间的划分】

Sun JDK实现时遵照JVM规范，将内存空间划分为方法区、堆、JVM方法栈、本地方法栈及pc寄存器。

* 方法区：

存放要加载的类or接口的信息（名称、修饰符等）、类的static变量、final常量、Field信息、方法信息（元数据）。通过Class对象获取的相关数据就来自该区域。 --见Class类

Sun JDK中这块区域对应Permanet Generation（持久代），默认最小值为16MB，最大值为64MB，可通过-XX:PermSize及-XX:MaxPermSize来设置最小值和最大值。

* 堆（Heap Memory）：

存放对象实例及数组值，Heap中对象所占用的内存由GC进行回收，在32位系统上最大为2G，64位系统上无限制。可通过-Xms和-Xmx控制，-Xms为JVM启动时申请的最小Heap内存，-Xmx为JVM可申请的最大Heap内存。

* 方法栈：

每个线程均会创建PC寄存器和方法栈。方法栈中有栈帧。方法栈为线程私有。当方法运行完毕，该方法对应的栈帧所占用的空间自动释放。

--想到 ThreadLocal

方法栈空间不足时，抛出StackOverflowError错误（如不合理的递归调用），在Sun JDK中可通过-Xss设置大小。

【Heap Memory详解】

{    [  (Eden)(S0)(S1)  ]     [ (          ) ]    }

　   |----New Gen------|    |-Old Gen--|

|---------------heap-----------------------|

-New Generation:新生代

大多数情况下java程序中新建的对象都从新生代分配内存，新生代由Eden Space和两块相同大小的Survivor Space构成。可通过-Xmn指定新生代的大小。

　　-Eden Space：创建对象，依据的是方法区中存放的类的元数据。

　　-S0：当Eden Space空间用完时，JVM的垃圾回收器对其进行回收，将Eden中不被其他对象使用的对象进行销毁，同时将Eden中还被其他对象引用的对象移到S0区，如果S0区也没有空间了则移动到S1区。

　　-S1

-Old Generation：旧生代

存放新生代中经过多次垃圾回收仍然存活的对象，例如缓存对象。旧生代占用大小为-Xmx值减-Xmn对应的值。

------Shallow Heap

java.lang.OutOfMemoryError: GC overhead limit exceeded

这个是JDK6新添的错误类型。是发生在GC占用大量时间而很少的堆被恢复的时候发生的，是一种保护机制。解决方案是，关闭该功能，使用 -XX:-UseGCOverheadLimit

Sun官方解释：

The parallel / concurrent collector will throw anOutOfMemoryErrorif too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option-XX:-UseGCOverheadLimitto the command line

如何避免：查看是否有使用大内存的代码或死循环。

【System.gc()与 finalize()】

java.lang.System.gc()

java.lang.Runtime.getRuntime().gc()

java.lang.Object.finalize()

一个题目:
11. rbo = new ReallyBigObject();
12. // more code here
13. rbo = null;
14.
Which statement should be placed at line 14to suggest that the virtual
machine expend effort towardrecycling the memory used by the
object rbo?
A. System.gc();
B. Runtime.getRuntaime().gc();
C. System.freeMemory();
D. Runtime.getRuntime().growHeap();
E. Runtime.getRuntime().freeMemory();

gc()有何用？

　　调用 gc 方法暗示着 Java 虚拟机做了一些努力来回收未用对象，以便能够快速地重用这些对象当前占用的内存。当控制权从方法调用中返回时，虚拟机已经尽最大努力从所有丢弃的对象中回收了空间。
调用 System.gc() 等效于调用Runtime.getRuntime().gc()

finalize()有何用？

　　gc 只能清除在堆上分配的内存(纯java语言的所有对象都在堆上使用new分配内存)，而不能清除栈上分配的内存（当使用JNI技术时,可能会在栈上分配内存，例如java调用c程序，而该c程序使用malloc分配内存时）。因此，如果某些对象被分配了栈上的内存区域，那gc就管不着了，对栈上的对象进行内存回收就要靠finalize()。
举个例子来说,当java 调用非java方法时（这种方法可能是c或是c++的）,在非java代码内部也许调用了c的malloc()函数来分配内存，而且除非调用那个了 free() 否则不会释放内存(因为free()是c的函数),这个时候要进行释放内存的工作,gc是不起作用的,因而需要在finalize()内部的一个固有方法调用free()。
finalize的工作原理应该是这样的：一旦垃圾收集器准备好释放对象占用的存储空间，它首先调用finalize()，而且只有在下一次垃圾收集过程中，才会真正回收对象的内存.所以如果使用finalize()，就可以在垃圾收集期间进行一些重要的清除或清扫工作.

finalize()在什么时候被调用?
有三种情况
1.所有对象被Garbage Collection时自动调用，比如运行System.gc()后.
2.程序退出时为每个对象调用一次finalize方法。
3.显式的调用finalize方法

除此以外，正常情况下,当某个对象被系统收集为无用信息的时候,finalize()将被自动调用。但是jvm不保证finalize()一定被调用,也就是说,finalize()的调用是不确定的,这也就是为什么sun不提倡使用finalize()的原因. 简单来讲，finalize()是在对象被GC回收前会调用的方法，而System.gc()建议而非强制GC开始回收工作，具体执行要看GC的执行策略。

调用了 System.gc() 之后，java 在内存回收过程中就会调用那些要被回收的对象的 finalize() 方法。

 

http://www.cnblogs.com/corson/archive/2012/01/04/2311974.html