【JVM】java的内存泄露问题

一、GC可回收的对象

二：什么是内存泄露
--->Java的一个最显著的优势是内存管理。你只需要简单的创建对象而不需要负责释放空间，因为Java的垃圾回收器会负责内存的回收。然而，情况并不是这样简单，内存泄露还是经常会在Java应用程序中出现
--->内存泄露的定义：对于应用程序来说，当对象已经不再被使用，但是Java的垃圾回收器不能回收它们的时候，就产生了内存泄露。要理解这个定义，我们需要理解对象在内存中的状态。
如下图所示，展示了哪些对象是无用对象，哪些是未被引用的对象；


---->上图中包含了未引用对象和引用对象。未引用对象将会被垃圾回收器回收，而引用对象却不会。未引用对象很显然是无用的对象。然而，无用的对象并不都是未引用对象，有一些无用对象也有可能是引用对象，这部分对象正是内存泄露的来源。


三：为什么会发生内存泄露
---->让我们用下面的例子来看看为什么会发生内存泄露。如下图所示，对象A引用对象B，A的生命周期（t1-t4）比B的生命周期（t2-t3）要长，当 B在程序中不再被使用的时候，A仍然引用着B。在这种情况下，垃圾回收器是不会回收B对象的，这就可能造成了内存不足问题，因为A可能不止引用着B对象， 还可能引用其它生命周期比A短的对象，这就造成了大量无用对象不能被回收，且占据了昂贵的内存资源。

---->同样的，B对象也可能引用着一大堆对象，这些被B对象引用着的对象也不能被垃圾回收器回收，所有的这些无用对象消耗了大量内存资源。



三：怎样阻止内存泄露

以下是一些阻止内存泄露的经验提示：

多关注集合类，比如HashMap，ArrayList等，这些对象经常会发生内存泄露。比如当它们被声明为静态对象时，它们的生命周期会跟应用程序的生命周期一样长，很容易造成内存不足。
多关注事件监听（listeners）和回调（callbacks），比如注册了一个listener，当它不再被使用的时候，忘了注销该listener，可能就会产生内存泄露。
“如果一个类自己管理自己的内存空间，开发人员需要特别警惕内存泄露”，引用其它对象的成员变量记得要置为null？不太理解（原文：Often times member variables of an object that point to other objects need to be null out）；


四：如果排查内存泄漏

（1）借助工具进行排查

最后一个重要的问题，就是如何检测Java的内存泄漏。目前，我们通常使用一些工具来检查Java程序的内存泄漏问题。市场上已有几种专业检查Java内存泄漏的工具，它们的基本工作原理大同小异，都是通过监测Java程序运行时，所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员将根据这些信息判断程序是否有内存泄漏问题。这些工具包括Optimizeit Profiler，JProbe Profiler，JinSight , Rational 公司的Purify等。

下面，我们将简单介绍Optimizeit的基本功能和工作原理。

Optimizeit Profiler版本4.11支持Application，Applet，Servlet和Romote Application四类应用，并且可以支持大多数类型的JVM，包括SUN JDK系列，IBM的JDK系列，和Jbuilder的JVM等。并且，该软件是由Java编写，因此它支持多种操作系统。Optimizeit系列还包括Thread Debugger和Code Coverage两个工具，分别用于监测运行时的线程状态和代码覆盖面。

当设置好所有的参数了，我们就可以在OptimizeIt环境下运行被测程序，在程序运行过程中，Optimizeit可以监视内存的使用曲线(如下图)，包括JVM申请的堆(heap)的大小，和实际使用的内存大小。另外，在运行过程中，我们可以随时暂停程序的运行，甚至强行调用GC，让GC进行内存回收。通过内存使用曲线，我们可以整体了解程序使用内存的情况。这种监测对于长期运行的应用程序非常有必要，也很容易发现内存泄露。

在运行过程中，我们还可以从不同视角观查内存的使用情况，Optimizeit提供了四种方式：

• 堆视角。 这是一个全面的视角，我们可以了解堆中的所有的对象信息(数量和种类)，并进行统计、排序，过滤。了解相关对象的变化情况。
• 方法视角。通过方法视角，我们可以得知每一种类的对象，都分配在哪些方法中，以及它们的数量。
• 对象视角。给定一个对象，通过对象视角，我们可以显示它的所有出引用和入引用对象，我们可以了解这个对象的所有引用关系。
• 引用图。 给定一个根，通过引用图，我们可以显示从该顶点出发的所有出引用。

在运行过程中，我们可以随时观察内存的使用情况，通过这种方式，我们可以很快找到那些长期不被释放，并且不再使用的对象。我们通过检查这些对象的生存周期，确认其是否为内存泄露。在实践当中，寻找内存泄露是一件非常麻烦的事情，它需要程序员对整个程序的代码比较清楚，并且需要丰富的调试经验，但是这个过程对于很多关键的Java程序都是十分重要的。

综上所述，Java也存在内存泄露问题，其原因主要是一些对象虽然不再被使用，但它们仍然被引用。为了解决这些问题，我们可以通过软件工具来检查内存泄露，检查的主要原理就是暴露出所有堆中的对象，让程序员寻找那些无用但仍被引用的对象。

 

（2）借助jvm自带的命令进行排查

===>先根据jmap查看当前系统的堆内存使用情况

命令：jmap -heap [pid]

jmap -heap 7907

Attaching to process ID 7907, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.45-b02

using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC

Heap Configuration:  //堆内存初始化配置
   MinHeapFreeRatio         = 40 //对应jvm启动参数-XX:MinHeapFreeRatio设置JVM堆最小空闲比率(default 40)
   MaxHeapFreeRatio         = 70 //对应jvm启动参数 -XX:MaxHeapFreeRatio设置JVM堆最大空闲比率(default 70)

   MaxHeapSize              = 4294967296 (4096.0MB) //对应jvm启动参数-XX:MaxHeapSize=设置JVM堆的最大大小

   NewSize                  = 1610612736 (1536.0MB) //对应jvm启动参数-XX:NewSize=设置JVM堆的‘新生代’的默认大小
   MaxNewSize               = 1610612736 (1536.0MB) //对应jvm启动参数-XX:MaxNewSize=设置JVM堆的‘新生代’的最大大小
   OldSize                  = 2684354560 (2560.0MB) //对应jvm启动参数-XX:OldSize=<value>:设置JVM堆的‘老生代’的大小

   NewRatio                 = 3 //对应jvm启动参数-XX:NewRatio=:‘新生代’和‘老生代’的大小比率
   SurvivorRatio            = 8 /对应jvm启动参数-XX:SurvivorRatio=设置年轻代中Eden区与Survivor区的大小比值 
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
   capacity = 1449590784 (1382.4375MB)
   used     = 58014328 (55.32677459716797MB)
   free     = 1391576456 (1327.110725402832MB)
   4.002117607281918% used
Eden Space:
   capacity = 1288568832 (1228.875MB)
   used     = 50841848 (48.48656463623047MB)
   free     = 1237726984 (1180.3884353637695MB)
   3.945605910790802% used
From Space:
   capacity = 161021952 (153.5625MB)
   used     = 7172480 (6.8402099609375MB)
   free     = 153849472 (146.7222900390625MB)
   4.454349180911681% used
To Space:
   capacity = 161021952 (153.5625MB)
   used     = 0 (0.0MB)
   free     = 161021952 (153.5625MB)
   0.0% used
concurrent mark-sweep generation:
   capacity = 2684354560 (2560.0MB)
   used     = 12372020067408 MB
   free     = 5473740762190789216 (5.220165979567327E12MB)
   -2.039127334768487E11% used

42244 interned Strings occupying 4466328 bytes.