java内存溢出

内存溢出(out of memory)通俗理解就是内存不够，通常在运行大型软件或游戏时，软件或游戏所需要的内存远远超出了你主机内安装的内存所承受大小，就叫内存溢出。

---

---

1 运行时数据区域

1.1 程序计数器

记录当前线程所执行字节码的行号指示器。线程私有，占有很小一块内存，【唯一一块没有OutOfMemoryError的区域。】

---

1.2 java虚拟机栈

线程私有，生命周期与线程一样，描述的是Java方法执行的区域：【每个方法被执行就回生成一个栈帧（Stack Frame）用于存储局部变量表，操作栈，动态链接，方法出口等信息。】

局部变量表存储编译器可知的各种基本数据类型（boolean byte char short int float long double)对象引用（reference）和returnAddress类型，其中float和double占用两个局部变量空间Slot，其余占用一个。
【两种异常：线程请求的深度大于虚拟机允许深度，StackOverFlowError，无法申请到足够的空间：OutOfMemoryError】

---

1.3本地方法栈

与虚拟机栈的作用相同，只不过执行的是本地方法Native，HotSpot把java虚拟机栈和本地方法栈合二为一。

无法申请到足够的空间：OutOfMemoryError unable to cteate new native thread

---

1.4 java堆（java Heap）

是内存中占用最大的一块，被所有线程共享。所有的对象实例和数组都在这上面分配，但是随着JIT编译器的发展和逃逸技术的成熟等，也不是那么绝对了。

Java堆是内存回收的主要区域，也成为“GC堆”（Garbage Collected Heap）。【如果无法申请到足够的空间抛出OutOfMemoryError ： Java heap space】

发生这种问题的原因是java虚拟机创建的对象太多，在进行垃圾回收之间，虚拟机分配的到堆内存空间已经用满了，与Heap space有关。解决这类问题有两种思路：

（1）检查程序，看是否有死循环或不必要地重复创建大量对象。找到原因后，修改程序和算法。
我以前写一个使用K-Means文本聚类算法对几万条文本记录（每条记录的特征向量大约10来个）进行文本聚类时，由于程序细节上有问题，就导致了Java heap space的内存溢出问题，后来通过修改程序得到了解决。

（2） 增加Java虚拟机中Xms（初始堆大小）和Xmx（最大堆大小）参数的大小。如：set JAVA_OPTS= -Xms256m -Xmx1024m

---

1.5 方法区

用来存储虚拟机加载的类信息，常量，静态常量，即时编译器编译后的代码等。也就是平时大家说的永久代，本质上并不等价，或者说使用永久代实现方法区而已。一般方法区内存回收成绩不令人满意。
【如果如法申请到足够的空间抛出OutOfMemoryError ：PermGen space】

发生这种问题的原意是程序中使用了大量的jar或class，使java虚拟机装载类的空间不够，与Permanent Generation space有关。解决这类问题有以下两种办法：

（1）增加java虚拟机中的XX:PermSize和XX:MaxPermSize参数的大小，其中XX:PermSize是初始永久保存区域大小，XX:MaxPermSize是最大永久保存区域大小。如针对tomcat6.0，在catalina.sh 或catalina.bat文件中一系列环境变量名说明结束处（大约在70行左右） 增加一行：
JAVA_OPTS=” -XX:PermSize=64M -XX:MaxPermSize=128m”
如果是windows服务器还可以在系统环境变量中设置。感觉用tomcat发布sprint+struts+hibernate架构的程序时很容易发生这种内存溢出错误。使用上述方法，我成功解决了部署ssh项目的tomcat服务器经常宕机的问题。

（2）清理应用程序中web-inf/lib下的jar，如果tomcat部署了多个应用，很多应用都使用了相同的jar，可以将共同的jar移到tomcat共同的lib下，减少类的重复加载。这种方法是网上部分人推荐的，我没试过，但感觉减少不了太大的空间，最靠谱的还是第一种方法。

---

1.6运行时常量池 （Runtime Constant Pool）

是方法区的一部分，Class文件除了有类的版本信息、字段方法接口外，还有一项信息是常量池，用于存放编译器生成的各种字面量和符号引用，这部分信息在类加载后存放到方法区的运行时常量池中。
具有动态性，【可以使用String类的intern（）方法加入】。

---

1.7直接内存

【并不是虚拟机运行时数据区的一部分】。*JDK1.4中引入了NIO类，引入了一种基于通道与缓冲区的I/O方式，可以使用Native直接分配堆外内存，避免了再Java堆和Native堆中来回复制数据。不会受到Java堆内存限制，但会受到机器总内存的限制。【如果如法申请到足够的空间抛出OutOfMemoryError。】*

---

---

2 对象访问

Object obj = new Object();

Object obj 会反映到java栈的本地变量表中，作为一个reference数据类型出现。New Object 会反映到堆中。Reference规定了一个指向对象的访问，主流访问方式有两种：

• 句柄访问，java堆中专门开辟出一块句柄池，reference指向句柄池，句柄池中包含了实际的对象地址，优点：reference稳定不用更改。
• 直接访问，reference直接指向对象，优点：速度快，Hotspot采用这种方式 。

---

---

3 OutOfMemoryError异常

3.1 Java堆异常

【堆的最小值：-Xms 如-Xms20m。
堆的最大值 -Xmx 如果设为一样的则可避免堆自动扩展。
年轻代大小： -Xmn
-XX：+HeapDumpOnOutOfMemoryError 当内存溢出时Dump出当前的内存堆转存快照。】
Eclipse中虚拟机参数设置：debug As–>open dubug dialog
生成之后使用Eclipse Memory Analyzer 进行堆转储文件分析（需要安装MAT插件）。

3.2 虚拟机栈和本地方法栈溢出

【Xss：设置每条线程的Statck大小。在JDK1.5以后默认是1M，之前是256K。】

抛出StackOverFlow异常：操作系统分配给每个线程的内存是有限的，机器总内存减去Xmx再减去MaxPermSize，程序计数器占内存很少忽略，剩下的内存被虚拟机栈和本地方法栈瓜分，每个线程分到的栈容量越大，分配的线程数就小。正常情况栈深度1000-2000没问题，如果是建立更多线程导致的内存溢出，在不能减少线程的情况下，只能通过减小Xmx和栈容量来换取更多线程。

3.3 方法区和运行时常量池溢出

【PermSize ：方法区的初始容量，默认是物理内存的1/64】
-MaxPermSize :最大方法区容量。

3.4 本机直接内存溢出

XX：MaxDirectMemorySize 本机直接内存大小，如果不指定，则与Xmx一样

---

---

4 内存溢出的解决

内存溢出虽然很棘手，但也有相应的解决办法，可以按照从易到难，一步步的解决。

4.1 就是修改JVM启动参数，直接增加内存。

这一点看上去似乎很简单，但很容易被忽略。JVM默认可以使用的内存为64M，Tomcat默认可以使用的内存为128MB，对于稍复杂一点的系统就会不够用。在某项目中，就因为启动参数使用的默认值，经常报“OutOfMemory”错误。因此，-Xms，-Xmx参数一定不要忘记加。

---

4.2 检查错误日志

检查错误日志，查看“OutOfMemory”错误前是否有其它异常或错误。在一个项目中，使用两个数据库连接，其中专用于发送短信的数据库连接使用DBCP连接池管理，用户为不将短信发出，有意将数据库连接用户名改错，使得日志中有许多数据库连接异常的日志，一段时间后，就出现“OutOfMemory”错误。经分析，这是由于DBCP连接池BUG引起的，数据库连接不上后，没有将连接释放，最终使得DBCP报“OutOfMemory”错误。经过修改正确数据库连接参数后，就没有再出现内存溢出的错误。

查看日志对于分析内存溢出是非常重要的，通过仔细查看日志，分析内存溢出前做过哪些操作，可以大致定位有问题的模块。

第三步，安排有经验的编程人员对代码进行走查和分析，找出可能发生内存溢出的位置。重点排查以下几点：

• 检查代码中是否有死循环或递归调用。
• 检查是否有大循环重复产生新对象实体。
• 检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
• 检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

---

4.4 使用内存查看工具动态查看内存使用情况

某个项目上线后，每次系统启动两天后，就会出现内存溢出的错误。这种情况一般是代码中出现了缓慢的内存泄漏，用上面三个步骤解决不了，这就需要使用内存查看工具了。

内存查看工具有许多，比较有名的有：Optimizeit Profiler、JProbe Profiler、JinSight和Java1.5的Jconsole等。它们的基本工作原理大同小异，都是监测Java程序运行时所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员可以根据这些信息判断程序是否有内存泄漏问题。一般来说，一个正常的系统在其启动完成后其内存的占用量是基本稳定的，而不应该是无限制的增长的。持续地观察系统运行时使用的内存的大小，可以看到在内存使用监控窗口中是基本规则的锯齿形的图线，如果内存的大小持续地增长，则说明系统存在内存泄漏问题。通过间隔一段时间取一次内存快照，然后对内存快照中对象的使用与引用等信息进行比对与分析，可以找出是哪个类的对象在泄漏。

---

通过以上四个步骤的分析与处理，基本能处理内存溢出的问题。当然，在这些过程中也需要相当的经验与敏感度，需要在实际的开发与调试过程中不断积累。

总体上来说，产生内存溢出是由于代码写的不好造成的，因此提高代码的质量是最根本的解决办法。有的人认为先把功能实现，有BUG时再在测试阶段进行修正，这种想法是错误的。正如一件产品的质量是在生产制造的过程中决定的，而不是质量检测时决定的，软件的质量在设计与编码阶段就已经决定了，测试只是对软件质量的一个验证，因为测试不可能找出软件中所有的BUG。