Jvm内存分配及解决(OutOfMemoryError)内存溢出问题

一.内存分配

程序运行时,对象是怎么进行放置安排的呢? 特别是内存是怎么分配的呢?

1.寄存器

这是最快的存储区,因为它位于不同与其他存储区的地方–处理器内部.

但是寄存器的数量是极其有限,所以寄存器根据需求进行分配.不能直接控制,也不能在程序中感觉到寄存器存在的任何迹象.

1.永久保存区 Permanent Generation space

存储：Class（类）和Meta的信息。Class第一次被Load的时候被放入PermGen space区域,class主要的存储内容主要包括方法和静态属性。

Java程序的每个线程中都有一个独立的堆栈。

2.栈 Java Stacks

存储:Java对象的引用，基本类型的变量，方法的输入输出参数。

位于通用RAM(随机访问存储器)中,通过堆栈指针可以从处理器那里获得直接支持.堆栈指针若向下移动,则分配新的内存. 若向上移动,则释放那些内存.

3.堆 Heap space

存储:存放Class的实例（所有的java对象，new出来的对象).对象需要储存的内容主要是非静态属性。这部分空间也被jvm的垃圾回收机制管理。

一种通用的内存池(也位于RAM区)

堆不同于堆栈的好处:编译器不需要知道存储的数据在堆里存活多长时间.

坏处:用堆进行存储分配和清理可能比用堆栈进行存储分配需要更多的时间

4.常量存储

常量值通常直接存放在程序代码内部,这样做是安全的,因为它们永远不会被改变.

有时,在嵌入式系统中,常量本身会和其他部分隔离开,所以在这种情况下,可以选择将其存放在ROM(只读存储器)中.

5.非RAM存储

如果数据完全存活于程序之外,那么它可以不受程序的任何控制,在程序没有运行时也可以存在.其中两个基本的例子是:流对象和持久化对象.

在’流对象’中,对象转化成字节流,通常被发送给另一台机器.

在’持久化对象’中,对象被存放于磁盘上,因此即使程序终止,它们仍可以保持自己的状态.

这种存储方式的技巧在于:把对象转化成可以存放在其他媒介上的事物,在需要时,可恢复成常规的,基于RAM的对象.java提供了对 轻量级持久化的支持,而诸如JDBC和Hibernate这样的机制提供了更加复杂的对在数据库中存储和读取对象信息的支持.

二.内存溢出

相信有一定java开发经验的人或多或少都会遇到OutOfMemoryError的问题。容易发生内存溢出问题的内存空间包括：Permanent Generation space和Heap space。

第一种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下，减少类的重复加载。这种方法是网上部分人推荐的，我没试过，但感觉减少不了太大的空间，最靠谱的还是第一种方法。

第二种OutOfMemoryError： Java heap space

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

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

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

第三种OutOfMemoryError：unable to create new native thread

在java应用中，有时候会出现这样的错误：OutOfMemoryError: unable to create new native thread.这种怪事是因为JVM已经被系统分配了大量的内存(比如1.5G)，并且它至少要占用可用内存的一半。有人发现，在线程个数很多的情况下，你分配给JVM的内存越多，那么，上述错误发生的可能性就越大。

那么是什么原因造成这种问题呢？

每一个32位的进程最多可以使用2G的可用内存，因为另外2G被操作系统保留。这里假设使用1.5G给JVM，那么还余下500M可用内存。这500M内存中的一部分必须用于系统dll的加载 ，那么真正剩下的也许只有400M，

现在关键的地方出现了：当你使用Java创建一个线程，在JVM的内存里也会创建一个Thread对象，但是同时也会在操作系统里创建一个真正的物理线程(参考JVM规范) ，操作系统会在余下的400兆内存里创建这个物理线程，而不是在JVM的1500M的内存堆里创建。在jdk1.4里头，默认的栈大小是256KB，但是在jdk1.5里头，默认的栈大小为1M每线程 ，因此，在余下400M的可用内存里边我们最多也只能创建400个可用线程。

这样结论就出来了，要想创建更多的线程，你必须减少分配给JVM的最大内存。还有一种做法是让JVM宿主在你的JNI代码里边。

给出一个有关能够创建线程的最大个数的估算公式：

(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads

对于jdk1.5而言，假设操作系统保留120M内存 ：1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads

1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads

对于栈大小为256KB的jdk1.4而言，

1.5GB allocated to JVM: ~1520 threads

1.0GB allocated to JVM: ~3520 threads

对于这个异常我们首先需要判断下，发生内存溢出时进程中到底都有什么样的线程，这些线程是否是应该存在的，是否可以通过优化来降低线程数； 另外一方面默认情况下java为每个线程分配的栈内存大小是1M，通常情况下，这1M的栈内存空间是足足够用了，因为在通常在栈上存放的只是基础类型的数据或者对象的引用，这些东西都不会占据太大的内存， 我们可以通过调整jvm参数，降低为每个线程分配的栈内存大小来解决问题，例如在jvm参数中添加-Xss128k 将线程栈内存大小设置为128k。

参考资料：

java编程思想–2.2章节

liqianbnu_331的博客：http://blog.sina.com.cn/s/blog_701c951f0100n1sp.html