1. Java GC回收算法
(1) 引用计数(Reference Counting)
比较古老的回收算法。原理是此对象有一个引用,即增加一个计数,删除一个引用则减少一个计数。垃圾回收时,只用收集计数为0的对象。此算法最致命的是无法处理循环引用的问题。
(2) 标记-清除(Mark-Sweep)此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象,第二阶段遍历整个堆,把未标记的对象清除。此算法需要暂停整个应用,同时,会产生内存碎片。
(3) 复制(Copying)此算法把内存空间划为两个相等的区域,每次只使用其中一个区域。垃圾回收时,遍历当前使用区域,把正在使用中的对象复制到另外一个区域中。此算法每次只处理正在使用中的对象,因此复制成本比较小,同时复制过去以后还能进行相应的内存整理,不会出现“内存碎片”问题。当然,此算法的缺点也是很明显的,就是需要两倍内存空间。
(4) 标记-整理(Mark-Compact)此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段,第一阶段从根节点开始标记所有被引用对象,第二阶段遍历整个堆,把清除未标记对象并且把存活对象“压缩”到堆的其中一块,按顺序排放。此算法避免了“标记-清除”的碎片问题,同时也避免了“复制”算法的空间问题。
2. 分代(Generational Collecting)
基于以上算法的优缺点,Java设计师们根据实际的运行场景,设计出了内存分代管理模型,它集中了以上多个算法的优势。把对象分为年青代、年老代、持久代,对不同生命周期的对象使用不同的算法(上述方式中的一个)进行回收。现在的垃圾回收器(从J2SE1.2开始)都是使用此算法的。
Java 的内存模型各个代的默认排列有如下图(适用JDK1.4.* 到 JDK6):
Java 的内存模型分为
Young(年轻代)--大部分对象需要及时回收,采用复制算法年轻代分三个区。一个Eden区,两个Survivor区。大部分对象在Eden区中生成。当Eden区满时,还存活的对象将被复制到Survivor区(两个中的一个),当这个Survivor区满时,此区的存活对象将被复制到另外一个Survivor区,当这个Survivor去也满了的时候,从第一个Survivor区复制过来的并且此时还存活的对象,将被复制“年老区(Tenured)”。需要注意,Survivor的两个区是对称的,没先后关系,所以同一个区中可能同时存在从Eden复制过来 对象,和从前一个Survivor复制过来的对象,而复制到年老区的只有从第一个Survivor去过来的对象。而且,Survivor区总有一个是空的。
Tenured(年老代)---需要回收的对象相对较少并且分散,采用 标记-整理(Mark-Compact)算法年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。
Perm(持久代)用于存放静态文件,如今Java类、方法等。持久代对垃圾回收没有显著影响,但是有些应用可能动态生成或者调用一些class,例如Hibernate等,在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=<N>进行设置。
堆内存优化:
调整JVM启动参数-Xms -Xmx -XX:newSize -XX:MaxNewSize,如调整初始堆内存和最大对内存 -Xms256M -Xmx512M。 或者调整初始New Generation的初始内存和最大内存 -XX:newSize=128M -XX:MaxNewSize=128M。
永久区内存优化:
调整PermSize参数 如 -XX:PermSize=256M -XX:MaxPermSize=512M。
栈内存优化:
调整每个线程的栈内存容量 如 -Xss2048K
一个运行中的JVM所占的内存= 堆内存 + 永久区内存 + 所有线程所占的栈内存总和
3. 防止内存泄漏的一些方法
(1)字符串,数字等尽量使用直接量,少用对象;
(2)使用StringBuild,StringBuffer进行字符串拼接;
(3)尽早释放无用对象的引用;
(4)尽量少用静态变量;
(5)缓存经常使用的对象;
Java默认的赋值语句为强引用;
软引用,SoftReference类来实现,在内存比较紧张时,会被GC回收;
弱引用,WeakReference类来实现,不论内存是否紧张,都会被GC回收;
5. Java内存泄漏的含义
Java内存泄漏的根本在于堆中不再使用的Java对象还和栈中的变量保持着引用关系,导致这些对象迟迟不能被回收而引起的
内存不够的现象。
Java和C++中的内存泄漏是不一样的,C++中对象生命周期完全由程序员控制,一旦程序忘记释放对象内存,后续就没机会释放了。
本文参考以下文档:
http://blog.chinaunix.net/uid-21547257-id-97977.html
(1) 引用计数(Reference Counting)
比较古老的回收算法。原理是此对象有一个引用,即增加一个计数,删除一个引用则减少一个计数。垃圾回收时,只用收集计数为0的对象。此算法最致命的是无法处理循环引用的问题。
(2) 标记-清除(Mark-Sweep)此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象,第二阶段遍历整个堆,把未标记的对象清除。此算法需要暂停整个应用,同时,会产生内存碎片。
(3) 复制(Copying)此算法把内存空间划为两个相等的区域,每次只使用其中一个区域。垃圾回收时,遍历当前使用区域,把正在使用中的对象复制到另外一个区域中。此算法每次只处理正在使用中的对象,因此复制成本比较小,同时复制过去以后还能进行相应的内存整理,不会出现“内存碎片”问题。当然,此算法的缺点也是很明显的,就是需要两倍内存空间。
(4) 标记-整理(Mark-Compact)此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段,第一阶段从根节点开始标记所有被引用对象,第二阶段遍历整个堆,把清除未标记对象并且把存活对象“压缩”到堆的其中一块,按顺序排放。此算法避免了“标记-清除”的碎片问题,同时也避免了“复制”算法的空间问题。
2. 分代(Generational Collecting)
基于以上算法的优缺点,Java设计师们根据实际的运行场景,设计出了内存分代管理模型,它集中了以上多个算法的优势。把对象分为年青代、年老代、持久代,对不同生命周期的对象使用不同的算法(上述方式中的一个)进行回收。现在的垃圾回收器(从J2SE1.2开始)都是使用此算法的。
Java 的内存模型各个代的默认排列有如下图(适用JDK1.4.* 到 JDK6):
Java 的内存模型分为
Young(年轻代)--大部分对象需要及时回收,采用复制算法年轻代分三个区。一个Eden区,两个Survivor区。大部分对象在Eden区中生成。当Eden区满时,还存活的对象将被复制到Survivor区(两个中的一个),当这个Survivor区满时,此区的存活对象将被复制到另外一个Survivor区,当这个Survivor去也满了的时候,从第一个Survivor区复制过来的并且此时还存活的对象,将被复制“年老区(Tenured)”。需要注意,Survivor的两个区是对称的,没先后关系,所以同一个区中可能同时存在从Eden复制过来 对象,和从前一个Survivor复制过来的对象,而复制到年老区的只有从第一个Survivor去过来的对象。而且,Survivor区总有一个是空的。
Tenured(年老代)---需要回收的对象相对较少并且分散,采用 标记-整理(Mark-Compact)算法年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。
Perm(持久代)用于存放静态文件,如今Java类、方法等。持久代对垃圾回收没有显著影响,但是有些应用可能动态生成或者调用一些class,例如Hibernate等,在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=<N>进行设置。
堆内存优化:
调整JVM启动参数-Xms -Xmx -XX:newSize -XX:MaxNewSize,如调整初始堆内存和最大对内存 -Xms256M -Xmx512M。 或者调整初始New Generation的初始内存和最大内存 -XX:newSize=128M -XX:MaxNewSize=128M。
永久区内存优化:
调整PermSize参数 如 -XX:PermSize=256M -XX:MaxPermSize=512M。
栈内存优化:
调整每个线程的栈内存容量 如 -Xss2048K
一个运行中的JVM所占的内存= 堆内存 + 永久区内存 + 所有线程所占的栈内存总和
3. 防止内存泄漏的一些方法
(1)字符串,数字等尽量使用直接量,少用对象;
(2)使用StringBuild,StringBuffer进行字符串拼接;
(3)尽早释放无用对象的引用;
(4)尽量少用静态变量;
(5)缓存经常使用的对象;
(6)适当时候可以考虑使用软引用,弱引用
Java默认的赋值语句为强引用;
软引用,SoftReference类来实现,在内存比较紧张时,会被GC回收;
弱引用,WeakReference类来实现,不论内存是否紧张,都会被GC回收;
5. Java内存泄漏的含义
Java内存泄漏的根本在于堆中不再使用的Java对象还和栈中的变量保持着引用关系,导致这些对象迟迟不能被回收而引起的
内存不够的现象。
Java和C++中的内存泄漏是不一样的,C++中对象生命周期完全由程序员控制,一旦程序忘记释放对象内存,后续就没机会释放了。
本文参考以下文档:
http://blog.chinaunix.net/uid-21547257-id-97977.html