Java 内存管理总结

阅读量：5752 次

发布时间：2019-06-18

本文共 7650 字，大约阅读时间需要 25 分钟。

1、Java中的finalize

finalize-方法名。Java 技术允许使用 finalize() 方法在垃圾收集器将对象从内存中清除出去之前做必要的清理工作。这个方法是由垃圾收集器在确定这个对象没有被引用时对这个对象调用的。它是在 Object 类中定义的，因此所有的类都继承了它。子类覆盖 finalize() 方法以整理系统资源或者执行其他清理工作。finalize() 方法是在垃圾收集器删除对象之前对这个对象调用的。

垃圾收集器只知道释放那些由new分配的内存，所以不知道如何释放对象的“特殊”内存。为解决这个问题，Java提供了一个名为finalize()的方法，它的工作原理应该是这样的：一旦垃圾收集器准备好释放对象占用的存储空间，它首先调用finalize()，而且只有在下一次垃圾收集过程中，才会真正回收对象的内存。所以如果使用finalize()，就可以在垃圾收集期间进行一些重要的清除或清扫工作(如关闭流等操作)。

　 Finalize 操作具有下列限制：

垃圾回收过程中执行终结器的准确时间是不确定的。不保证资源在任何特定的时间都能释放，除非调用 Close 方法或 Dispose 方法。

即使一个对象引用另一个对象，也不能保证两个对象的终结器以任何特定的顺序运行。即，如果对象 A 具有对对象 B 的引用，并且两者都有终结器，则当对象 A 的终结器启动时，对象 B 可能已经终结了。

运行终结器的线程是未指定的。

在下面的异常情况下，Finalize 方法可能不会运行完成或可能根本不运行：

另一个终结器无限期地阻止（进入无限循环，试图获取永远无法获取的锁，诸如此类）。由于运行时试图运行终结器来完成，所以如果一个终结器无限期地阻止，则可能不会调用其他终结器。

进程终止，但不给运行时提供清理的机会。在这种情况下，运行时的第一个进程终止通知是 DLL_PROCESS_DETACH 通知。

在关闭过程中，只有当可终结对象的数目继续减少时，运行时才继续 Finalize 对象。

如果 Finalize 或 Finalize 的重写引发异常，并且运行库并非寄宿在重写默认策略的应用程序中，则运行库将终止进程，并且不执行任何活动的 try-finally 块或终结器。如果终结器无法释放或销毁资源，此行为可以确保进程完整性。

给实现者的说明默认情况下，Object.Finalize 不执行任何操作。只有在必要时才必须由派生类重写它，因为如果必须运行 Finalize 操作，垃圾回收过程中的回收往往需要长得多的时间。如果 Object 保存了对任何资源的引用，则 Finalize 必须由派生类重写，以便在垃圾回收过程中，在放弃 Object 之前释放这些资源。当类型使用文件句柄或数据库连接这类在回收使用托管对象时必须释放的非托管资源时，该类型必须实现 Finalize。有关辅助和具有更多控制的资源处置方式，请参见 IDisposable 接口。 Finalize 可以采取任何操作，包括在垃圾回收过程中清理了对象后使对象复活（即，使对象再次可访问）。但是，对象只能复活一次；在垃圾回收过程中，不能对复活对象调用 Finalize。

析构函数是执行清理操作的 C# 机制。析构函数提供了适当的保护措施，如自动调用基类型的析构函数。在 C# 代码中，不能调用或重写 Object.Finalize。

2、Java内存分配解析

Java内存分配与管理是Java的核心技术之一，之前我们曾介绍过Java的内存管理与内存泄露以及Java垃圾回收方面的知识，今天我们再次深入Java核心，详细介绍一下Java在内存分配方面的知识。一般Java在内存分配时会涉及到以下区域：

◆寄存器：我们在程序中无法控制

◆栈：存放基本类型的数据和对象的引用，但对象本身不存放在栈中，而是存放在堆中

◆堆：存放用new产生的数据

◆静态域：存放在对象中用static定义的静态成员

◆常量池：存放常量

◆非RAM存储：硬盘等永久存储空间

常量池 (constant pool)

常量池指的是在编译期被确定，并被保存在已编译的.class文件中的一些数据。除了包含代码中所定义的各种基本类型（如int、long等等）和对象型（如String及数组）的常量值(final)还包含一些以文本形式出现的符号引用，比如：

◆类和接口的全限定名；

◆字段的名称和描述符；

◆方法和名称和描述符。

解释几段程序：

String str1="Hello";

String str2="Hello";

String str3 = new String("Hello");

String str4 = new String("Hello");

System.out.println(str1==str2);

结果为true，因为 str1和str2指向同一块常量池内存块。类似C中得指针指向同一个内存地址.

System.out.println(str1==str3);

结果为false，因为 str1和str2指向同一块常量池内存块。类似C中得指针指向同一个内存地址.

System.out.println(str3==str4);

结果为false,因为str3和str4虽然所指向的字符串对象是等值的，但是所指向的区域是不同的，就像是比较指针，呵呵，有点怀念C++ 了。

再补充介绍一点：存在于.class文件中的常量池，在运行期被JVM装载，并且可以扩充。String的 intern()方法就是扩充常量池的一个方法；当一个String实例str调用intern()方法时，Java 查找常量池中是否有相同Unicode的字符串常量，如果有，则返回其的引用，如果没有，则在常量池中增加一个Unicode等于str的字符串并返回它的引用。

再解释一段程序：

String str1="Hello";

String str2= new String("Hello");

System.out.println(str1==str2.intern());

结果为true，因为string调用intern()方法，会到常量池去寻找“Hello”常量，如果找到就直接把这个常量的引用返回了，所以str1和str2指向的是同一个引用。

3、Java的垃圾回收算法

* 引用计数

该算法在Java虚拟机没被使用过，主要是循环引用问题，因为计数并不记录谁指向他，无法发现这些交互自引用对象。（感觉有点类似C++中的智能指针的计数机制）

-- 怎么计数？

当引用连接到对象时，对象计数加1

当引用离开作用域或被置为null时减1

-- 怎么回收？

遍历对象列表，计数为0就释放

-- 有什么问题？

循环引用问题。A引用B，B引用A，那么A,B就永远都不会被释放

* 标记算法

标记算法的思想是从堆栈和静态存储区的对象开始，遍历所有引用，标记活得对象。

对于标记后有两种处理方式：

(1) 停止-复制

-- 所谓停止，就是停止在运行的程序，进行垃圾回收

-- 所谓复制，就是将活得对象复制到另外一个堆上，以使内存更紧凑

-- 优点在于，当大块内存释放时，有利于整个内存的重分配

-- 有什么问题？

一、停止，干扰程序的正常运行，

二、复制，明显耗费大量时间，

三，如果程序比较稳定，垃圾比较少，那么每次重新复制量是非常大的，非常不合算

-- 什么时候启动停止-复制？

内存数量较低时，具体多低我也不知道

(2) 清除也称标记-清除算法

-- 也就是将标记为非活得对象释放，也必须暂停程序运行

-- 优点就是在程序比较稳定，垃圾比较少的时候，速度比较快

-- 有什么问题?

很显然停止程序运行是一个问题，只清除也会造成很对内存碎片。

-- 为什么这2个算法都要暂停程序运行？

这是因为，如果不暂停，刚才的标记会被运行的程序弄乱

关于Java垃圾回收算法不存在一个绝对完美的算法。垃圾回收算法还是一个复杂的研究领域，不存在任何简单而通用的解决方案，因此标记-清除只是一个用来理解垃圾回收机制的相对简单的智力模型。每种Java虚拟机都有自己的垃圾回收模型策略。

4、JVM内存模型

Java堆的描述如下：

内存由 Perm 和 Heap 组成. 其中

Heap = {Old + NEW = { Eden , from, to } }

JVM内存模型中分两大块，一块是 NEW Generation, 另一块是Old Generation. 在New Generation中，有一个叫Eden的空间，主要是用来存放新生的对象，还有两个Survivor Spaces（from,to）, 它们用来存放每次垃圾回收后存活下来的对象。在Old Generation中，主要存放应用程序中生命周期长的内存对象，还有个Permanent Generation，主要用来放JVM自己的反射对象，比如类对象和方法对象等。

垃圾回收描述：

在New Generation块中，垃圾回收一般用Copying的算法，速度快。每次GC的时候，存活下来的对象首先由Eden拷贝到某个Survivor Space, 当Survivor Space空间满了后, 剩下的live对象就被直接拷贝到Old Generation中去。因此，每次GC后，Eden内存块会被清空。在Old Generation块中，垃圾回收一般用mark-compact的算法，速度慢些，但减少内存要求.

垃圾回收分多级，0级为全部(Full)的垃圾回收，会回收OLD段中的垃圾；1级或以上为部分垃圾回收，只会回收NEW中的垃圾，内存溢出通常发生于OLD段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。

当一个URL被访问时，内存申请过程如下：
A. JVM会试图为相关Java对象在Eden中初始化一块内存区域

B. 当Eden空间足够时，内存申请结束。否则到下一步

C. JVM试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）, 释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区

D. Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区

E. 当OLD区空间不够时，JVM会在OLD区进行完全的垃圾收集（0级）

F. 完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory错误”

JVM调优建议:

ms/mx：定义YOUNG+OLD段的总尺寸，ms为JVM启动时YOUNG+OLD的内存大小；mx为最大可占用的YOUNG+OLD内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。

NewSize/MaxNewSize：定义YOUNG段的尺寸，NewSize为JVM启动时YOUNG的内存大小；MaxNewSize为最大可占用的YOUNG内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。

PermSize/MaxPermSize：定义Perm段的尺寸，PermSize为JVM启动时Perm的内存大小；MaxPermSize为最大可占用的Perm内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。

SurvivorRatio：设置Survivor空间和Eden空间的比例

内存溢出的可能性

1. OLD段溢出

这种内存溢出是最常见的情况之一，产生的原因可能是：

1) 设置的内存参数过小(ms/mx, NewSize/MaxNewSize)

2) 程序问题

单个程序持续进行消耗内存的处理，如循环几千次的字符串处理，对字符串处理应建议使用StringBuffer。此时不会报内存溢出错，却会使系统持续垃圾收集，无法处理其它请求，相关问题程序可通过Thread Dump获取（见系统问题诊断一章）单个程序所申请内存过大，有的程序会申请几十乃至几百兆内存，此时JVM也会因无法申请到资源而出现内存溢出，对此首先要找到相关功能，然后交予程序员修改，要找到相关程序，必须在Apache日志中寻找。

当Java对象使用完毕后，其所引用的对象却没有销毁，使得JVM认为他还是活跃的对象而不进行回收，这样累计占用了大量内存而无法释放。由于目前市面上还没有对系统影响小的内存分析工具，故此时只能和程序员一起定位。

2. Perm段溢出

通常由于Perm段装载了大量的Servlet类而导致溢出，目前的解决办法：

1) 将PermSize扩大，一般256M能够满足要求

2) 若别无选择，则只能将servlet的路径加到CLASSPATH中，但一般不建议这么处理

3. C Heap溢出

系统对C Heap没有限制，故C Heap发生问题时，Java进程所占内存会持续增长，直到占用所有可用系统内存

其他：

JVM有2个GC线程。第一个线程负责回收Heap的Young区。第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区。Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。

为什么一些程序频繁发生GC？有如下原因：

1、程序内调用了System.gc()或Runtime.gc()。

2、一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。