‘壹’ java程序内存溢出一般什么原因
JVM内存设置小了 或者一次性读的数据过大 例如list vertor
一、内存溢出类型
1、java.lang.OutOfMemoryError: PermGen space
JVM管理两种类型的内存，堆和非堆。堆是给开发人员用的上面说的就是，是在JVM启动时创建；非堆是留给JVM自己用的，用来存放类的信息的。它和堆不同，运行期内GC不会释放空间。如果web
app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。
PermGen space的全称是Permanent Generation
space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen
space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen
space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre
compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。
一个最佳的配置例子：(经过本人验证，自从用此配置之后，再未出现过tomcat死掉的情况)
set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m
-XX:MaxPermSize=256m
2、java.lang.OutOfMemoryError: Java heap space
第一种情况是个补充，主要存在问题就是出现在这个情况中。其默认空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。如果内存剩余不到40％，JVM就会增大堆到Xmx设置的值，内存剩余超过70％，JVM就会减小堆到Xms设置的值。所以服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小。假设物理内存无限大，那么JVM内存的最大值跟操作系统有关，一般32位机是1.5g到3g之间，而64位的就不会有限制了。
注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。
垃圾回收GC的角色
JVM调用GC的频度还是很高的，主要两种情况下进行垃圾回收：
当应用程序线程空闲；另一个是java内存堆不足时，会不断调用GC，若连续回收都解决不了内存堆不足的问题时，就会报out of
memory错误。因为这个异常根据系统运行环境决定，所以无法预期它何时出现。
根据GC的机制，程序的运行会引起系统运行环境的变化，增加GC的触发机会。
为了避免这些问题，程序的设计和编写就应避免垃圾对象的内存占用和GC的开销。显示调用System.GC()只能建议JVM需要在内存中对垃圾对象进行回收，但不是必须马上回收，
一个是并不能解决内存资源耗空的局面，另外也会增加GC的消耗。
二、JVM内存区域组成
简单的说java中的堆和栈
java把内存分两种：一种是栈内存，另一种是堆内存
1。在函数中定义的基本类型变量和对象的引用变量都在函数的栈内存中分配；
2。堆内存用来存放由new创建的对象和数组
在函数（代码块）中定义一个变量时，java就在栈中为这个变量分配内存空间，当超过变量的作用域后，java会自动释放掉为该变量所分配的内存空间；在堆中分配的内存由java虚拟机的自动垃圾回收器来管理
堆的优势是可以动态分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的。缺点就是要在运行时动态分配内存，存取速度较慢；
栈的优势是存取速度比堆要快，缺点是存在栈中的数据大小与生存期必须是确定的无灵活性。
java堆分为三个区：New、Old和Permanent
GC有两个线程：
新创建的对象被分配到New区，当该区被填满时会被GC辅助线程移到Old区，当Old区也填满了会触发GC主线程遍历堆内存里的所有对象。Old区的大小等于Xmx减去-Xmn
java栈存放
栈调整：参数有+UseDefaultStackSize -Xss256K，表示每个线程可申请256k的栈空间
每个线程都有他自己的Stack
三、JVM如何设置虚拟内存
提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。
提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。
提示：JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4。
默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC
后调整堆的大小。
提示：假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。
简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，
这个限制一般是2GB-3GB（一般来说Windows系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了
提示：注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。
提示：设置NewSize、MaxNewSize相等，"new"的大小最好不要大于"old"的一半，原因是old区如果不够大会频繁的触发"主" GC
，大大降低了性能
JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；
由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。
解决方法：手动设置Heap size
修改TOMCAT_HOME/bin/catalina.bat
在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"
四、性能检查工具使用
定位内存泄漏：
JProfiler工具主要用于检查和跟踪系统（限于Java开发的）的性能。JProfiler可以通过时时的监控系统的内存使用情况，随时监视垃圾回收，线程运行状况等手段，从而很好的监视JVM运行情况及其性能。
1. 应用服务器内存长期不合理占用，内存经常处于高位占用，很难回收到低位；
2. 应用服务器极为不稳定，几乎每两天重新启动一次，有时甚至每天重新启动一次；
3. 应用服务器经常做Full GC(Garbage Collection)，而且时间很长，大约需要30-40秒，应用服务器在做Full
GC的时候是不响应客户的交易请求的，非常影响系统性能。
因为开发环境和产品环境会有不同，导致该问题发生有时会在产品环境中发生，通常可以使用工具跟踪系统的内存使用情况，在有些个别情况下或许某个时刻确实是使用了大量内存导致out
of memory，这时应继续跟踪看接下来是否会有下降，
如果一直居高不下这肯定就因为程序的原因导致内存泄漏。
五、不健壮代码的特征及解决办法
1、尽早释放无用对象的引用。好的办法是使用临时变量的时候，让引用变量在退出活动域后，自动设置为null，暗示垃圾收集器来收集该对象，防止发生内存泄露。
对于仍然有指针指向的实例，jvm就不会回收该资源,因为垃圾回收会将值为null的对象作为垃圾，提高GC回收机制效率；
2、我们的程序里不可避免大量使用字符串处理，避免使用String，应大量使用StringBuffer，每一个String对象都得独立占用内存一块区域；
String str = "aaa";
String str2 = "bbb";
String str3 = str + str2;//假如执行此次之后str
,str2以后再不被调用,那它就会被放在内存中等待Java的gc去回收,程序内过多的出现这样的情况就会报上面的那个错误,建议在使用字符串时能使用StringBuffer就不要用String,这样可以省不少开销；
3、尽量少用静态变量，因为静态变量是全局的，GC不会回收的；
4、避免集中创建对象尤其是大对象，JVM会突然需要大量内存，这时必然会触发GC优化系统内存环境；显示的声明数组空间，而且申请数量还极大。
这是一个案例想定供大家警戒
使用jspsmartUpload作文件上传,运行过程中经常出现java.outofMemoryError的错误，
检查之后发现问题：组件里的代码
m_totalBytes = m_request.getContentLength();
m_binArray = new byte[m_totalBytes];
问题原因是totalBytes这个变量得到的数极大，导致该数组分配了很多内存空间，而且该数组不能及时释放。解决办法只能换一种更合适的办法，至少是不会引发outofMemoryError的方式解决。参考：http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=3747
5、尽量运用对象池技术以提高系统性能；生命周期长的对象拥有生命周期短的对象时容易引发内存泄漏，例如大集合对象拥有大数据量的业务对象的时候，可以考虑分块进行处理，然后解决一块释放一块的策略。
6、不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。可以适当的使用hashtable，vector
创建一组对象容器，然后从容器中去取那些对象，而不用每次new之后又丢弃
7、一般都是发生在开启大型文件或跟数据库一次拿了太多的数据，造成 Out Of Memory Error
的状况，这时就大概要计算一下数据量的最大值是多少，并且设定所需最小及最大的内存空间值。
‘贰’ Java循环创建多个对象后导致内存溢出！
在解决java内存溢出问题之前，需要对jvm（java虚拟机）的内存管理有一定的认识。jvm管理的内存大致包括三种不同类型的内存区域：Permanent Generation space（永久保存区域）、Heap space(堆区域)、Java Stacks(Java栈）。其中永久保存区域主要存放Class（类）和Meta的信息，Class第一次被Load的时候被放入PermGen space区域，Class需要存储的内容主要包括方法和静态属性。堆区域用来存放Class的实例（即对象），对象需要存储的内容主要是非静态属性。每次用new创建一个对象实例后，对象实例存储在堆区域中，这部分空间也被jvm的垃圾回收机制管理。而Java栈跟大多数编程语言包括汇编语言的栈功能相似，主要基本类型变量以及方法的输入输出参数。Java程序的每个线程中都有一个独立的堆栈。容易发生内存溢出问题的内存空间包括：Permanent Generation space和Heap space。
第一种OutOfMemoryError： PermGen space
发生这种问题的原意是程序中使用了大量的jar或class，使java虚拟机装载类的空间不够，与Permanent Generation space有关。解决这类问题有以下两种办法：
增加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服务器经常宕机的问题。
清理应用程序中web-inf/lib下的jar，如果tomcat部署了多个应用，很多应用都使用了相同的jar，可以将共同的jar移到tomcat共同的lib下，减少类的重复加载。这种方法是网上部分人推荐的，我没试过，但感觉减少不了太大的空间，最靠谱的还是第一种方法。
第二种OutOfMemoryError： Java heap space
发生这种问题的原因是java虚拟机创建的对象太多，在进行垃圾回收之间，虚拟机分配的到堆内存空间已经用满了，与Heap space有关。解决这类问题有两种思路：
检查程序，看是否有死循环或不必要地重复创建大量对象。找到原因后，修改程序和算法。 我以前写一个使用K-Means文本聚类算法对几万条文本记录（每条记录的特征向量大约10来个）进行文本聚类时，由于程序细节上有问题，就导致了Java heap space的内存溢出问题，后来通过修改程序得到了解决。
增加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。
‘叁’ 7、如何让Java中的静态常量池内存溢出
/**
* VM Args：-XX:PermSize=10M -XX:MaxPermSize=10M （jdk1.6）
*/
public class RuntimeConstantPoolOOM {
public static void main(String[] args) {
// 使用List保持着常量池引用，避免Full GC回收常量池行为
List<String> list = new ArrayList<String>();
// 10MB的PermSize在integer范围内足够产生OOM了
int i = 0;
while (true) {
list.add(String.valueOf(i++).intern());
}
}
}
‘肆’ 什么时候会发生jvm堆内存溢出内存溢出了怎么办
简单的来说 java的堆内存分为两块:permantspace（持久带） 和 heap space。
持久带中主要存放用于存放静态类型数据，如 Java Class, Method 等， 与垃圾收集器要收集的Java对象关系不大。
而heapspace分为年轻带和年老带
年轻代的垃圾回收叫 Young GC， 年老代的垃圾回收叫 Full GC。
在年轻代中经历了N次（可配置）垃圾回收后仍然存活的对象，就会被复制到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象
年老代溢出原因有 循环上万次的字符串处理、创建上千万个对象、在一段代码内申请上百M甚至上G的内存
持久代溢出原因 动态加载了大量Java类而导致溢出
‘伍’ JAVA递归，静态方法为什么容易溢出
jvm的问题，java 没有尾递归优化，每次调用方法的时候，都会在栈中创建一个新栈帧，在递归完成前，此栈帧一直被使用，不能被释放掉，所以当递归次数太多的时候就容易内存溢出
‘陆’ 如何检查和解决java虚拟机内存溢出的问题
一，jvm内存区域
1， 程序计数器
一块很小的内存空间，作用是当前线程所执行的字节码的行号指示器。
2， java栈
与程序计数器一样，java栈（虚拟机栈）也是线程私有的，其生命周期与线程相同。通常存放基本数据类型，对象引用（一个指向对象起始地址的引用指针或一个代表对象的句柄），reeturnAddress类型（指向一条字节码指令的地址）
栈区域有两种异常类型：如果线程请求的栈深度大于虚拟机所允许的深度，将抛StrackOverflowError异常；如果虚拟机栈可以动态扩展（大部分虚拟机都可动态扩展），当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常。
3， 本地方法栈
与虚拟机栈作用很相似，区别是虚拟机栈为虚拟机执行java方法服务，而本地方法栈则是为虚拟机用到的Native方法服务。和虚拟机栈一样可能抛出StackOverflowError和OutOfMemoryError异常。
4， java堆
java
Heap是jvm所管理的内存中最大的区域。JavaHeap是被所有线程共享的一块内存区域，在虚拟机启动时创建。主要存放对象实例。JavaHeap
是垃圾收集器管理的主要区域，其可细分为新生代和老年代。如果在堆中没有内存完成实例分配，并且也无法再扩展时，会抛出OutOfMemoryError
异常。
5， 方法区
与javaHeap一样是各个线程共享的内存区域，用于存放已被虚拟机加载的类信息、常量、静态变量、及时编译器编译后的代码等数据。当方法区无法满足内
存分配的需求时，将抛出OutOfMemoryError异常。方法同时包含常听说的运行时常量池，用于存放编译期生成的各种字面量和符号引用。
6， 直接内存
直接内存并不是虚拟机运行时数据区的一部分，也不是java虚拟机规范中定义的内存区域，是jvm外部的内存区域，这部分区域也可能导致OutOfMemoryError异常。
二，jvm参数
-Xss（StackSpace）栈空间
-Xms ，-Xmx（heap memory
space）堆空间：Heap是大家最为熟悉的区域，他是jvm用来存储对象实例的区域，Heap在32位的系统中最大为2G，其大小通过-Xms和
-Xmx来控制，-Xms为jvm启动时申请的最小Heap内存，默认为物理内存的1/64，但小于1G，-Xmx为jvm可申请的最大的Heap内存，
默认为物理内存的1/4,一般也小于1G，默认当空余堆内存小于40%时，jvm会最大Heap的大小到-Xmx指定大小，可通过
-XX:MinHeapFreeRatio来指定这个比例，当空余堆内存大于70%时，JVM会将Heap的大小往-Xms指定的大小调整，可通过
-XX:MaxHeapFreeRatio来指定这个比例，但通常为了避免频繁调整HeapSize的大小，将-Xms和-Xmx的值设为相同。
-XX:PermSize -XX:MaxPermSize ：方法区持久代大小： 方法区域也是全局共享的，在一定的条件下它也会被 GC ，当方法区域需要使用的内存超过其允许的大小时，会抛出 OutOfMemory 的错误信息。
三，常见内存溢出错误解决办法
1， OutOfMemoryError异常
除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError(OOM)异常的可能，
Java Heap 溢出
一般的异常信息：java.lang.OutOfMemoryError:Java heap spacess
java堆用于存储对象实例，我们只要不断的创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，就会在对象数量达到最大堆容量限制后产生内存溢出异常。
出现这种异常，一般手段是先通过内存映像分析工具(如Eclipse Memory
Analyzer)对mp出来的堆转存快照进行分析，重点是确认内存中的对象是否是必要的，先分清是因为内存泄漏(Memory
Leak)还是内存溢出(Memory Overflow)。
如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象时通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收。
如果不存在泄漏，那就应该检查虚拟机的参数(-Xmx与-Xms)的设置是否适当。
2， 虚拟机栈和本地方法栈溢出
如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。
如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常
这里需要注意当栈的大小越大可分配的线程数就越少。
3， 运行时常量池溢出
异常信息：java.lang.OutOfMemoryError:PermGen space
如果要向运行时常量池中添加内容，最简单的做法就是使用String.intern()这个Native方法。该方法的作用是：如果池中已经包含一个等于
此String的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String
对象的引用。由于常量池分配在方法区内，我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小，从而间接限制其中常量
池的容量。
4， 方法区溢出
方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。
异常信息：java.lang.OutOfMemoryError:PermGen space
方法区溢出也是一种常见的内存溢出异常，一个类如果要被垃圾收集器回收，判定条件是很苛刻的。在经常动态生成大量Class的应用中，要特别注意这点。
‘柒’ 在java项目开发中过多使用静态变量和方法容易产生什么问题
java项目开发中过多使用静态变量可能产生的问题如下：
1.内存空间的使用问题。静态空间在程序结束之前一直存在，从而造成内存空间使用率不高。
2.另一个问题就是如果在函数中使用了静态变量，那么这个函数就会保存上一次调用的一个状态，有时这会导致一些比较微妙的错误。特别的，这样的函数是不可重入的，不能在多线程或者多进程中进行使用。
‘捌’ 关于java的静态方法使用问题
静态方法在JVM刚加载的时候就编译过了...在程序的运行过程中随时可以调用...不需要去实例化某个对象然后再去调用...可以直接用类名去调用...不过你想一下,在JVM刚加载的进修就编译过了..也就是说它一直存在着...也就是说它一直占用这内存中的地址空间...所以说也是比较占资源，而动态方法只有被调用的时候才会占有资源，所以说如果考虑内存的情况时，尽量少用静态方法