Author：Martin
E-mail：mwdnjupt@sina.com.cn
CSDN Blog:http://blog.csdn.net/ictcamera
Sina MicroBlog ID:ITCamera
Main Reference：
《java深度历险》 王森
《深入理解Java虚拟机-java高级特性与最佳实践》 周志明
- Java性能问题，谁是罪魁祸首？
- 不良的架构？
- 不恰当的线程同步？
- 资源的不恰当使用导致的资源竞争？
- 不恰当的虚拟机运行参数？
- 缓慢的磁盘/网络 IO？
- 内存泄漏－过分相信Java的自动垃圾回收机制？
- ......
1. 内存溢出OutOfMemoryError?
如果没有足够内存来满足申请要求，Java虚拟机就抛出OutOfMemoryError异常，这里主要包括Java堆、栈、方法区申请不到内存的情况。
1.1. 内存溢出的原因
对于这个问题总结起来原因无非两个：“地方调小”和“人太多”
- 地方小：JVM在启动时是固定分配了一定的堆栈大小，如果参数配置有误，那么就易出现内存溢出。参数如：堆（-Xms –Xmx）；栈（-Xss，-Xoss）方法区（-XX:PermSize
-XX:MaxPermSize） - 人多：Java虽然可以自动进行GC，并且对外屏蔽了内存分配，但是依然是存在内存泄露，如果分配的内存不能回收，那么就存在内存溢出风险。
措施：如果“地方就这么大了”，那么应该减少“人”，调整对象的生存周期，“让人及时离开”。
1.2. 内存泄漏
不应该存在的对象还存在，说明内存泄漏了。
措施：应该修改代码逻辑，应该离开的人必须离开。内存泄漏的主要原因一般是该释放的资源没有释放。
1.3. 内存溢出三种主要类型
OutOfMemoryError: Java heap space
对于使用容器时，一定要考虑容器的最大值，不能无限制的插入内容。数据容器不受限的增长是出现内存溢出的主要原因之一，因这些在调试环境下比较难以出现，只要在压力测试下才有可能造成溢出，所以对于List、HashMap、HashTable、Cache、Queue等需要特别进行注意。并且在这些实例在作为参数传递的过程中，因为生命周期处理不好也会因为引用关系而造成内存泄露。
OutOfMemoryError: PermGen space
PermGen space的全称是Permanent Generation space,是指内存的永久保存区域。这一部分用于存放Class和Meta的信息,Class在被
Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,GC(Garbage
Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen
space错误。这种错误常见在web服务器对JSP进行pre compile的时候。但目前的hibernate和spring项目中也很容易出现这样的问题。http://www.javaeye.com/topic/80620?page=1 的帖子有讨论的这个问题。可能是由于这些框架会动态class，而且jvm的gc是不会清理PemGen
space的，导致内存溢出。
OutOfMemoryError: unable to create new native thread
如果虚拟机栈允许动态扩展，当扩展无法申请到足够的内存时会抛出OutOfMemoryError。
当然这种现象比较少见，也比较奇怪，主要是和JVM与系统内存的比例有关。这种怪事是因为JVM已经被系统分配了大量的内存(比如1.5G)，并且它至少要占用可用内存的一半。有人发现，在线程个数很多的情况下，你分配给JVM的内存越多，那么，上述错误发生的可能性就越大。产生这种现象的原因如下：
每一个32位的进程最多可以使用2G的可用内存，因为另外2G被操作系统保留。这里假设使用1.5G给JVM，那么还余下500M可用内存。这500M内存中的一部分必须用于系统dll的加载，那么真正剩下的也许只有400M，现在关键的地方出现了：当你使用Java创建一个线程，在JVM的内存里也会创建一个Thread对象，但是同时也会在操作系统里创建一个真正的物理线程(参考JVM规范)，操作系统会在余下的400M内存里创建这个物理线程，而不是在JVM的1500M的内存堆里创建。在JDK1.4里头，默认的栈大小是256KB，但是在JDK1.5里头，默认的栈大小为1M/线程，因此，在余下400M的可用内存里边我们最多也只能创建400个可用线程。
这样结论就出来了，要想创建更多的线程，你必须减少分配给JVM的最大内存。还有一种做法是让JVM宿主在你的JNI代码里边。
如果上面的情况不存在，也还有一种情况，如果Java虚拟机分配了最大的内存为2G，那么栈内存约等于2G减去最大堆内存和方法区部分，如果最大堆内存很大，那么剩下的栈内存就很少，而没个栈的帧大小是固定的，因此线程数量是有限的，这时候线程数量过多也会导致OutOfMemoryError或者StackOverflowError。
如果是建立过多的线程导致内存溢出，在不能减少线程数量或者跟换虚拟机的情况下，之间减少最大堆和减少栈容量来换取更多的线程。下面给出一个有关能够创建线程的最大个数的估算公式：
(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 |
1.4. 内存溢出和内存泄漏
内存异常可能是内存泄漏的原因（对象不断的积累），也可能对象的确需要存在。没有发生内存逸出的情况下也可能存在内存泄漏。
1.5. 内存溢出日志收集
set jvm_opts=%jvm_opts% -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=%program_inst_log_dir%dump-%nodename%-%date_time_string%.hprof
这个参数的作用就是在进程出现OutOfMemory时自动的将heap dump到文件中，文件目录存放的目录，由环境变量指定。
2. 运行很慢?
如果程序运行很慢，原因分为如下两大类：
- 外部（数据库、Log、Socket等IO）
- 线程死锁、线程活锁、死循环
3. Java虚拟机性能工具
3.1. JDK命令行工具
jps、jstat、jinfo、jmap、jhat、jstack,其中后三个最有用
3.2. JDK可视化工具—JConsole
JDK命令工具的可视化
3.3. JDK可视化工具—VisualVM
Java自带的内存分析工具。适合平时自己开发时，看看自己的代码内存是否能被回收。
优点：
1，操作简单、实时性较好，可以即时连接到网管中，查看多个堆栈。
2，可以先进行垃圾回收，再查看堆栈，减少能回收数据的影响
3，图形化界面比较友好，过滤方式很实用
缺点：
1，慢，尤其是计算保留大小时，1G的堆栈要半小时或更多。
2，没有什么建议，问题都需要自己分析，找问题比较耗时。
3，不支持Linux的dump文件。
3.4. Memory Analyzer Tool
和Eclipse集成的内存分析工具。适合出现未知OOM问题时，问题的初步定位。
优点：
1，建议功能很实用，在不知道为什么dump的情况下，建议可以指出查看方向
2，加载完毕后，就已经计算出了保留的大小
缺点：
1，过滤功能做的不好，要定位某个类只能自己找。
2，只能分析dump文件。
3，不支持Linux的dump文件。
3.5. HeapAnalyzer
HeapAnalyzer,IBM开发的工具，可以支持linux下的堆栈（*.bin）
优点：
1，支持Linux的dump文件。（唯一选择他的理由）
2，有简单的分析
3，工具本身较小（5M）
缺点：
1，界面易用性较差
2，容易导致眼花
3.6. 其他
JProfiler（没尝试过）、JProbe（很老了）等等