Java堆
内存映像分析工具，检查是否是内存泄露，还是内存溢出。
2.4.2 虚拟机栈和本地方法栈溢出
本地变量表。StackOverflowError异常。（栈帧太大）
2.4.3 方法区 + 运行时常量池溢出
运行时常量池：字符串常量池 String.intern()
方法区溢出
存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。
思路：运行时产生大量的类去填满方法区，直到溢出。
JVM上的动态语言。
2.4.4 本机直接内存溢出
NIO相关。明显的特征：Heap Dump文件中不会看见明显的异常，即OOM后Dump文件很小。
|
java.lang.OutOfMemoryError: PermGen space
|
但问题是为什么这些王牌的开源会出现同一个问题呢，那么是不是更基础的原因呢？tomcat在Q&A很隐晦的回答了这一点，我们知道这个问题，但这个问题是由一个更基础的问题产生。
于是有人对更基础的JVM做了检查，发现了问题的关键。原来SUN 的JVM把内存分了不同的区，其中一个就是permenter区用来存放用得非常多的类和类描述。本来SUN设计的时候认为这个区域在JVM启动的时候就固定了，但他没有想到现在动态会用得这么广泛。而且这个区域有特殊的垃圾收回机制，现在的问题是动态加载类到这个区域后，gc根本没办法回收！
原因：
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)那么就会产生此错误信息了。
解决方法：
1. 手动设置MaxPermSize大小
修改TOMCAT_HOME/bin/catalina.bat（Linux下为catalina.sh），在
“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m
catalina.sh下为：
|
java.lang.OutOfMemoryError: Java heap space
|
解释：
Heap size 设置
JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。
提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。
提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。
解决方法：
手动设置Heap size
修改TOMCAT_HOME/bin/catalina.bat，在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
或修改catalina.sh 在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
一、JVM内存区域组成
java把内存分四种：
1、栈区（stack segment）— 由编译器自动分配释放,存放函数的参数值，局部变量的值等，具体方法执行结束之后，系统自动释放内存资源
2、堆区（heap segment） — 一般由程序员分配释放，存放由new创建的对象和数组，jvm不定时查看这个对象，如果没有引用指向这个对象就回收
3、静态区（data segment）— 存放全局变量，静态变量和字符串常量，不释放
4、代码区（code segment）— 存放程序中方法的二进制代码，而且是多个对象 共享一个代码空间区域
在方法（代码块）中定义一个变量时，java就在栈中为这个变量分配内存空间，当超过变量的作用域后，java会自动释放掉为该变量所分配的内存空间；在堆中分配的内存由java虚拟机的自动垃圾回收器来管理，堆的优势是可以动态分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的。缺点就是要在运行时动态分配内存，存取速度较慢；栈的优势是存取速度比堆要快，缺点是存在栈中的数据大小与生存期必须是确定的无灵活性。
java堆由Perm区和Heap区组成，Heap区则由Old区和New区组成，而New区又分为Eden区, From区, To区，Heap = {Old + NEW = { Eden, From, To } }，见图1所示。
Heap区分两大块，一块是 NEW Generation, 另一块是Old Generation. 在New Generation中，有一个叫Eden的空间，主要是用来存放新生的对象，还有两个Survivor Spaces（from,to）, 它们用来存放每次垃圾回收后存活下来的对象。在Old Generation中，主要存放应用程序中生命周期长的内存对象，还有个Permanent Generation，主要用来放JVM自己的反射对象，比如类对象和方法对象等。
在New Generation块中，垃圾回收一般用Copying的算法，速度快。每次GC的时候，存活下来的对象首先由Eden拷贝到某个Survivor Space, 当Survivor Space空间满了后, 剩下的live对象就被直接拷贝到Old Generation中去。因此，每次GC后，Eden内存块会被清空。在Old Generation块中，垃圾回收一般用mark-compact的算法，速度慢些，但减少内存要求.
垃圾回收分多级，0级为全部(Full)的垃圾回收，会回收OLD段中的垃圾；1级或以上为部分垃圾回收，只会回收NEW中的垃圾，内存溢出通常发生于OLD段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。
根据GC的机制，程序的运行会引起系统运行环境的变化，增加GC的触发机会。为了避免这些问题，程序的设计和编写就应避免垃圾对象的内存占用和GC的开销。显示调用System.GC()只能建议JVM需要在内存中对垃圾对象进行回收，但不是必须马上回收，一个是并不能解决内存资源耗空的局面，另外也会增加GC的消耗。
当一个URL被访问时，内存申请过程如下：
A. JVM会试图为相关Java对象在Eden中初始化一块内存区域
B. 当Eden空间足够时，内存申请结束。否则到下一步
C. JVM试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）, 释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区
D. Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区
E. 当OLD区空间不够时，JVM会在OLD区进行完全的垃圾收集（0级）
F. 完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现"out of memory错误"
二、内存溢出类型
1、java.lang.OutOfMemoryError: PermGen space
JVM管理两种类型的内存，堆和非堆。堆是给开发人员用的，是在JVM启动时创建；非堆是留给JVM自己用的，用来存放类的信息的。它和堆不同，运行期内GC不会释放空间。如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。
2、java.lang.OutOfMemoryError: Java heap space
这种内存溢出是最常见的情况之一，主要体现在Old区的溢出，产生的原因可能是：1) 设置的内存参数过小(ms/mx, NewSize/MaxNewSize)；2) 程序问题。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值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。
3、java.lang.OutOfMemoryError: c heap space
系统对C Heap没有限制，故C Heap发生问题时，Java进程所占内存会持续增长，直到占用所有可用系统内存
4、其他
JVM有2个GC线程。第一个线程负责回收Heap的Young区。第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区。Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。
为什么一些程序频繁发生GC？有如下原因：
a、程序内调用了System.gc()或Runtime.gc()。
b、一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。
c、Java的Heap太小，一般默认的Heap值都很小。
d、频繁实例化���象，Release对象。此时尽量保存并重用对象，例如使用StringBuffer()和String()。
如果你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态。许多Server端的Java程序每次GC后最好能有65%的剩余空间
三、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 ，大大降低了性能
提示：增加Heap Size 虽然会降低GC的频率，但也增加了每次GC的时间。并且GC运行时，所有的用户线程将暂停，也就是GC期间，Java应用程序不做任何工作。
提示：Heap Size 并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值，因为Java为其他任务分配内存，例如每个线程的Stack等。
提示：每个线程都有他自己的Stack，Stack Size 限制着线程的数量。如果Stack过大就好导致内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。如果Stack太小，也会导致Stack溢漏。
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"
四、不健壮代码的特征及解决办法
1、尽早释放无用对象的引用。好的办法是使用临时变量的时候，让引用变量在退出活动域后，自动设置为null，暗示垃圾收集器来收集该对象，防止发生内存泄露。对于仍然有指针指向的实例，jvm就不会回收该资源,因为垃圾回收会将值为null的对象作为垃圾，提高GC回收机制效率；
2、我们的程序里不可避免大量使用字符串处理，避免使用String，应大量使用StringBuffer，每一个String对象都得独立占用内存一块区域；例如
3、尽量少用静态变量，因为静态变量是全局的，GC不会回收的；
4、避免集中创建对象尤其是大对象，JVM会突然需要大量内存，这时必然会触发GC优化系统内存环境；显示的声明数组空间，而且申请数量还极大。
5、尽量运用对象池技术以提高系统性能；生命周期长的对象拥有生命周期短的对象时容易引发内存泄漏，例如大集合对象拥有大数据量的业务对象的时候，可以考虑分块进行处理，然后解决一块释放一块的策略。
6、不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。可以适当的使用hashtable，vector 创建一组对象容器，然后从容器中去取那些对象，而不用每次new之后又丢弃
7、一般都是发生在开启大型文件或跟数据库一次拿了太多的数据，造成 Out Of Memory Error 的状况，这时就大概要计算一下数据量的最大值是多少，并且设定所需最小及最大的内存空间值。
【如何写出会发生内存泄露的Java代码】
Vector v = new Vector(10);
for (int i = 1; i<100; i++)
{Object o = new Object();
v.add(o);
o = null;
}
java中我们是通过引用来操作对象的。
比如Object o = new Object();
这里的o是引用，根据o能找到新创建的对象，但是o并不是这个对象。
打个比方，o就是一个门牌号，通过门牌号能找到放对象的地方。
v.add(o);就是你把门牌号放到里面了，也就是说v通过内部的信息还能找到对象，对象不是垃圾。
这个例子没有体现内存泄漏，但是用来理解内存泄漏的潜在发生可能还是可以的。
不需要那么复杂，一个非常简单的例子就能说明问题：
Object o1 = new Object();
Object o2 = o1;
o1 = null; // 这时o1指向的那个对象回收了吗？没有，因为它还被o2引用着
o2 = null; // 这样才能回收
实际应用中，只要o2的作用域很小，不执行o2=null也是没有问题的，因为只要o2过了它的生存期，它指向的对象就能被回收。
结论是，作用域越大的变量，越要引起重视，因为它可能占用着某些对象引用而导致对象不能被回收。换句话说，尽可能地缩小变量的作用域——这也是你在Java中关于内存方面能做的唯一努力了。
A1：通过以下步骤可以很容易产生内存泄露（程序代码不能访问到某些对象，但是它们仍然保存在内存中）:
- 应用程序创建一个长时间运行的线程（或者使用线程池，会更快地发生内存泄露）。
- 线程通过某个类加载器（可以自定义）加载一个类。
- 该类分配了大块内存（比如new byte[1000000]），在某个静态变量存储一个强引用，然后在ThreadLocal中存储它自身的引用。分配额外的内存new byte[1000000]是可选的(类实例泄露已经足够了)，但是这样会使内存泄露更快。
- 线程清理自定义的类或者加载该类的类加载器。
- 重复以上步骤。
由于没有了对类和类加载器的引用，ThreadLocal中的存储就不能被访问到。ThreadLocal持有该对象的引用，它也就持有了这个类及其类加载器的引用，类加载器持有它所加载的类的所有引用，这样GC无法回收ThreadLocal中存储的内存。在很多JVM的实现中Java类和类加载器直接分配到permgen区域不执行GC，这样导致了更严重的内存泄露。
这种泄露模式的变种之一就是如果你经常重新部署以任何形式使用了ThreadLocal的应用程序、应用容器（比如Tomcat）会很容易发生内存泄露（由于应用容器使用了如前所述的线程，每次重新部署应用时将使用新的类加载器）。
A2：
静态变量引用对象
1 |
class MemorableClass { |
2 |
static final ArrayList list = new ArrayList(100); |
3 |
} |
调用长字符串的String.intern()
1 |
String str=readString(); // read lengthy string any source db,textbox/jsp etc.. |
2 |
// This will place the string in memory pool from which you cant remove |
3 |
str.intern(); |
未关闭已打开流(文件，网络等)
1 |
try { |
2 |
BufferedReader br = new BufferedReader(new FileReader(inputFile)); |
3 |
... |
4 |
... |
5 |
} catch (Exception e) { |
6 |
e.printStacktrace(); |
7 |
} |
未关闭连接
1 |
try { |
2 |
Connection conn = ConnectionFactory.getConnection(); |
3 |
... |
4 |
... |
5 |
} catch (Exception e) { |
6 |
e.printStacktrace(); |
7 |
} |
JVM的GC不可达区域
比如通过native方法分配的内存。
web应用在application范围的对象，应用未重启或者没有显式移除
getServletContext().setAttribute("SOME_MAP", map);
web应用在session范围的对象，未失效或者没有显式移除
session.setAttribute("SOME_MAP", map);
不正确或者不合适的JVM选项
比如IBM JDK的noclassgc阻止了无用类的垃圾回收
A3：如果HashSet未正确实现(或者未实现)hashCode()或者equals(),会导致集合中持续增加“副本”。如果集合不能地忽略掉它应该忽略的元素，它的大小就只能持续增长，而且不能删除这些元素。
如果你想要生成错误的键值对，可以像下面这样做：
1 |
class BadKey { |
2 |
// no hashCode or equals(); |
3 |
public final String key; |
4 |
public BadKey(String key) { this.key = key; } |
5 |
} |
6 |
|
7 |
Map map = System.getProperties(); |
8 |
map.put(new BadKey("key"), "value"); // Memory leak even if your threads die. |
A4：除了被遗忘的监听器，静态引用，hashmap中key错误/被修改或者线程阻塞不能结束生命周期等典型内存泄露场景，下面介绍一些不太明显的Java发生内存泄露的情况，主要是线程相关的。
- Runtime.addShutdownHook后没有移除，即使使用了removeShutdownHook，由于ThreadGroup类对于未启动线程的bug，它可能不被回收，导致ThreadGroup发生内存泄露。
- 创建但未启动线程，与上面的情形相同
- 创建继承了ContextClassLoader和AccessControlContext的线程，ThreadGroup和InheritedThreadLocal的使用，所有这些引用都是潜在的泄露，以及所有被类加载器加载的类和所有静态引用等等。这对ThreadFactory接口作为重要组成元素整个j.u.c.Executor框架(java.util.concurrent)的影响非常明显，很多开发人员没有注意到它潜在的危险。而且很多库都会按照请求启动线程。
- ThreadLocal缓存，很多情况下不是好的做法。有很多基于ThreadLocal的简单缓存的实现，但是如果线程在它的期望生命周期外继续运行ContextClassLoader将发生泄露。除非真正必要不要使用ThreadLocal缓存。
- 当ThreadGroup自身没有线程但是仍然有子线程组时调用ThreadGroup.destroy()。发生内存泄露将导致该线程组不能从它的父线程组移除，不能枚举子线程组。
- 使用WeakHashMap，value直接(间接)引用key，这是个很难发现的情形。这也适用于继承Weak/SoftReference的类可能持有对被保护对象的强引用。
- 使用http(s)协议的java.net.URL下载资源。KeepAliveCache在系统ThreadGroup创建新线程，导致当前线程的上下文类加载器内存泄露。没有存活线程时线程在第一次请求时创建，所以很有可能发生泄露。(在Java7中已经修正了，创建线程的代码合理地移除了上下文类加载器。)
- 使用InflaterInputStream在构造函数(比如PNGImageDecoder)中传递new java.util.zip.Inflater()，不调用inflater的end()。仅仅是new的话非常安全，但如果自己创建该类作为构造函数参数时调用流的close()不能关闭inflater，可能发生内存泄露。这并不是真正的内存泄露因为它会被finalizer释放。但这消耗了很多native内存，导致linux的oom_killer杀掉进程。所以这给我们的教训是：尽可能早地释放native资源。
- java.util.zip.Deflater也一样，它的情况更加严重。好的地方可能是很少用到Deflater。如果自己创建了Deflater或者Inflater记住必须调用end()。