asp公司企业网站模板源代码,100种迷你小手工,wordpress缩略图利器,自己建网站写小说对象引用Java 中的垃圾回收一般是在 Java 堆中进行#xff0c;因为堆中几乎存放了 Java 中所有的对象实例。谈到 Java 堆中的垃圾回收#xff0c;自然要谈到引用。在 JDK1.2 之前#xff0c;Java 中的引用定义很很纯粹#xff1a;如果 reference 类型的数据中存储的数值代表…对象引用Java 中的垃圾回收一般是在 Java 堆中进行因为堆中几乎存放了 Java 中所有的对象实例。谈到 Java 堆中的垃圾回收自然要谈到引用。在 JDK1.2 之前Java 中的引用定义很很纯粹如果 reference 类型的数据中存储的数值代表的是另外一块内存的起始地址就称这块内存代表着一个引用。但在 JDK1.2 之后Java 对引用的概念进行了扩充将其分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)、虚引用(Phantom Reference)四种引用强度依次减弱。强引用如“Object obj new Object()”这类引用是 Java 程序中最普遍的。只要强引用还存在垃圾收集器就永远不会回收掉被引用的对象。软引用它用来描述一些可能还有用但并非必须的对象。在系统内存不够用时这类引用关联的对象将被垃圾收集器回收。JDK1.2 之后提供了 SoftReference 类来实现软引用。弱引用它也是用来描述非需对象的但它的强度比软引用更弱些被弱引用关联的对象只能生存岛下一次垃圾收集发生之前。当垃圾收集器工作时无论当前内存是否足够都会回收掉只被弱引用关联的对象。在 JDK1.2 之后提供了 WeakReference 类来实现弱引用。虚引用最弱的一种引用关系完全不会对其生存时间构成影响也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的是希望能在这个对象被收集器回收时收到一个系统通知。JDK1.2 之后提供了 PhantomReference 类来实现虚引用。垃圾对象的判定Java 堆中存放着几乎所有的对象实例垃圾收集器对堆中的对象进行回收前要先确定这些对象是否还有用判定对象是否为垃圾对象有如下算法引用计数算法给对象添加一个引用计数器每当有一个地方引用它时计数器值就加 1当引用失效时计数器值就减1任何时刻计数器都为 0 的对象就是不可能再被使用的。引用计数算法的实现简单判定效率也很高在大部分情况下它都是一个不错的选择当 Java 语言并没有选择这种算法来进行垃圾回收主要原因是它很难解决对象之间的相互循环引用问题。根搜索算法Java 和 C# 中都是采用根搜索算法来判定对象是否存活的。这种算法的基本思路是通过一系列名为“GC Roots”的对象作为起始点从这些节点开始向下搜索搜索所走过的路径称为引用链当一个对象到 GC Roots 没有任何引用链相连时就证明此对象是不可用的。在 Java 语言里可作为 GC Roots 的兑现包括下面几种虚拟机栈(栈帧中的本地变量表)中引用的对象。方法区中的类静态属性引用的对象。方法区中的常量引用的对象。本地方法栈中 JNI(Native 方法)的引用对象。实际上在根搜索算法中要真正宣告一个对象死亡至少要经历两次标记过程如果对象在进行根搜索后发现没有与 GC Roots 相连接的引用链那它会被第一次标记并且进行一次筛选筛选的条件是此对象是否有必要执行 finalize()方法。当对象没有覆盖 finalize()方法或 finalize()方法已经被虚拟机调用过虚拟机将这两种情况都视为没有必要执行。如果该对象被判定为有必要执行 finalize()方法那么这个对象将会被放置在一个名为 F-Queue 队列中并在稍后由一条由虚拟机自动建立的、低优先级的 Finalizer 线程去执行 finalize()方法。finalize()方法是对象逃脱死亡命运的最后一次机会(因为一个对象的 finalize()方法最多只会被系统自动调用一次)稍后 GC 将对 F-Queue 中的对象进行第二次小规模的标记如果要在 finalize()方法中成功拯救自己只要在 finalize()方法中让该对象重引用链上的任何一个对象建立关联即可。而如果对象这时还没有关联到任何链上的引用那它就会被回收掉。垃圾收集算法判定除了垃圾对象之后便可以进行垃圾回收了。下面介绍一些垃圾收集算法由于垃圾收集算法的实现涉及大量的程序细节因此这里主要是阐明各算法的实现思想而不去细论算法的具体实现。标记—清除算法标记—清除算法是最基础的收集算法它分为“标记”和“清除”两个阶段首先标记出所需回收的对象在标记完成后统一回收掉所有被标记的对象它的标记过程其实就是前面的根搜索算法中判定垃圾对象的标记过程。标记—清除算法的执行情况如下图所示回收前状态回收后状态标记—整理算法复制算法比较适合于新生代在老年代中对象存活率比较高如果执行较多的复制操作效率将会变低所以老年代一般会选用其他算法如标记—整理算法。该算法标记的过程与标记—清除算法中的标记过程一样但对标记后出的垃圾对象的处理情况有所不同它不是直接对可回收对象进行清理而是让所有的对象都向一端移动然后直接清理掉端边界以外的内存。标记—整理算法的回收情况如下所示回收前状态回收后状态分代收集当前商业虚拟机的垃圾收集 都采用分代收集它根据对象的存活周期的不同将内存划分为几块一般是把 Java 堆分为新生代和老年代。在新生代中每次垃圾收集时都会发现有大量对象死去只有少量存活因此可选用复制算法来完成收集而老年代中因为对象存活率高、没有额外空间对它进行分配担保就必须使用标记—清除算法或标记—整理算法来进行回收。垃圾收集器垃圾收集器是内存回收算法的具体实现Java 虚拟机规范中对垃圾收集器应该如何实现并没有任何规定因此不同厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大的差别。Sun HotSpot 虚拟机 1.6 版包含了如下收集器Serial、ParNew、Parallel Scavenge、CMS、Serial Old、Parallel Old。这些收集器以不同的组合形式配合工作来完成不同分代区的垃圾收集工作。垃圾回收分析在用代码分析之前我们对内存的分配策略明确以下三点对象优先在 Eden 分配。大对象直接进入老年代。长期存活的对象将进入老年代。对垃圾回收策略说明以下两点新生代 GC(Minor GC)发生在新生代的垃圾收集动作因为 Java 对象大多都具有朝生夕灭的特性因此Minor GC 非常频繁一般回收速度也比较快。老年代 GC(Major GC/Full GC)发生在老年代的 GC出现了 Major GC经常会伴随至少一次 Minor GC。由于老年代中的对象生命周期比较长因此 Major GC 并不频繁一般都是等待老年代满了后才进行 Full GC而且其速度一般会比 Minor GC 慢 10 倍以上。另外如果分配了 Direct Memory在老年代中进行 Full GC时会顺便清理掉 Direct Memory 中的废弃对象。下面我们来看如下代码:public class SlotGc{public static void main(String[] args){byte[] holder new byte[32*1024*1024];System.gc();}}代码很简单就是向内存中填充了 32MB 的数据然后通过虚拟机进行垃圾收集。在 javac 编译后我们执行如下指令java -verbose:gc SlotGc 来查看垃圾收集的结果得到如下输出信息[GC 208K-134K(5056K), 0.0017306 secs][Full GC 134K-134K(5056K), 0.0121194 secs][Full GC 32902K-32902K(37828K), 0.0094149 sec注意第三行“-”之前的数据表示垃圾回收前堆中存活对象所占用的内存大小“-”之后的数据表示垃圾回收堆中存活对象所占用的内存大小括号中的数据表示堆内存的总容量0.0094149 sec 表示垃圾回收所用的时间。从结果中可以看出System.gc()运行后并没有回收掉这 32MB 的内存这应该是意料之中的结果因为变量holder 还处在作用域内虚拟机自然不会回收掉 holder 引用的对象所占用的内存。我们把代码修改如下public class SlotGc{public static void main(String[] args){{byte[] holder new byte[32*1024*1024];}System.gc();}}加入花括号后holder 的作用域被限制在了花括号之内因此在执行System.gc()时holder 引用已经不能再被访问逻辑上来讲这次应该会回收掉 holder 引用的对象所占的内存。但查看垃圾回收情况时输出信息如下[GC 208K-134K(5056K), 0.0017100 secs][Full GC 134K-134K(5056K), 0.0125887 secs][Full GC 32902K-32902K(37828K), 0.0089226 secs]很明显这 32MB 的数据并没有被回收。下面我们再做如下修改public class SlotGc{public static void main(String[] args){{byte[] holder new byte[32*1024*1024];holder null;}System.gc();}}这次得到的垃圾回收信息如下[GC 208K-134K(5056K), 0.0017194 secs][Full GC 134K-134K(5056K), 0.0124656 secs][Full GC 32902K-134K(37828K), 0.0091637 secs]说明这次 holder 引用的对象所占的内存被回收了。我们慢慢来分析。首先明确一点holder 能否被回收的根本原因是局部变量表中的 Slot 是否还存有关于 holder 数组对象的引用。在第一次修改中虽然在 holder 作用域之外进行回收但是在此之后没有对局部变量表的读写操作holder 所占用的 Slot 还没有被其他变量所复用(回忆 Java 内存区域与内存溢出一文中关于 Slot 的讲解)所以作为 GC Roots 一部分的局部变量表仍保持者对它的关联。这种关联没有被及时打断因此 GC 收集器不会将 holder 引用的对象内存回收掉。 在第二次修改中在 GC 收集器工作前手动将 holder 设置为 null 值就把 holder 所占用的局部变量表中的 Slot 清空了因此这次 GC 收集器工作时将 holder 之前引用的对象内存回收掉了。当然我们也可以用其他方法来将 holder 引用的对象内存回收掉只要复用 holder 所占用的 slot 即可比如在 holder 作用域之外执行一次读写操作。为对象赋 null 值并不是控制变量回收的最好方法以恰当的变量作用域来控制变量回收时间才是最优雅的解决办法。另外赋 null 值的操作在经过虚拟机 JIT 编译器优化后会被消除掉经过 JIT 编译后System.gc()执行时就可以正确地回收掉内存而无需赋 null 值。性能调优Java 虚拟机的内存管理与垃圾收集是虚拟机结构体系中最重要的组成部分对程序(尤其服务器端)的性能和稳定性有着非常重要的影响。性能调优需要具体情况具体分析而且实际分析时可能需要考虑的方面很多这里仅就一些简单常用的情况作简要介绍。我们可以通过给 Java 虚拟机分配超大堆(前提是物理机的内存足够大)来提升服务器的响应速度但分配超大堆的前提是有把握把应用程序的 Full GC 频率控制得足够低因为一次 Full GC 的时间造成比较长时间的停顿。控制 Full GC 频率的关键是保证应用中绝大多数对象的生存周期不应太长尤其不能产生批量的、生命周期长的大对象这样才能保证老年代的稳定。Direct Memory 在堆内存外分配而且二者均受限于物理机内存且成负相关关系因此分配超大堆时如果用到了 NIO 机制分配使用了很多的 Direct Memory则有可能导致 Direct Memory 的 OutOfMemoryError 异常这时可以通过 -XX:MaxDirectMemorySize 参数调整 Direct Memory 的大小。除了 Java 堆和永久代以及直接内存外还要注意下面这些区域也会占用较多的内存这些内存的总和会受到操作系统进程最大内存的限制1、线程堆栈可通过 -Xss 调整大小内存不足时抛出 StackOverflowError(纵向无法分配即无法分配新的栈帧)或 OutOfMemoryError(横向无法分配即无法建立新的线程)。2、Socket 缓冲区每个 Socket 连接都有 Receive 和 Send 两个缓冲区分别占用大约 37KB 和 25KB 的内存。如果无法分配可能会抛出 IOExceptionToo many open files 异常。关于 Socket 缓冲区的详细介绍参见我的 Java 网络编程系列中深入剖析 Socket 的几篇文章。3、JNI 代码如果代码中使用了JNI调用本地库那本地库使用的内存也不在堆中。4、虚拟机和 GC虚拟机和 GC 的代码执行也要消耗一定的内存。
