今天花了一整天在跟踪一个问题，每次感觉已经快找到原因的时候发现现象又变了，我觉得从中吸取的教训可以给大家分享一下。
为了重现这个现象，我写了一个简单的例子。在本例中，先初始化了一个map,然后用一个无限循环将一些键值对插入到map里面：
class Wrapper {
public static void main（String args[]） throws Exception {
Map map = System.getProperties（）；
Random r = new Random（）；
while （true） {
map.put（r.nextInt（）， "value"）；
}
}
}
你可能也猜到了，这段代码编译执行后无法正常结束。当我用这组参数启动的话：
java -Xmx100m -XX:+UseParallelGC Wrapper
我会在终端中看到java.lang.OutOfMemoryError: GC overhead limit exceeded的异常信息。不过如果我调整一下堆大小或者是GC的类型的话，在我的Mac OS X 10.9.2 系统上用Oracle Hotspot JDK 1.7.0_45来运行，就会出现不同的情况。
比如说，我用一个较小的堆来运行这个程序，就像下面这样：
java -Xmx10m -XX:+UseParallelGC Wrapper
应用程序会抛出一段大家更熟悉的错误信息然后挂掉：java.lang.OutOfMemoryError: Java heap space.
如果你换成ParallelGC以外的GC策略的话，比如说-XX:+UseConcMarkSweepGC or -XX:+UseG1GC,你将会看到由默认的异常处理器所抛出的异常，并且你看不到堆栈信息了，因为堆已经没有空间了，甚至连异常的堆栈信息都没法填充了，因此它在创建异常的时候就挂掉了：
My Precious:examples vladimir$ java -Xmx100m -XX:+UseConcMarkSweepGC Wrapper
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main"
这说明了什么？当资源紧缺的时候，你根本没法判断你的应用程序是怎么挂掉的，因此不要指望能出现你所预期的一系列错误提示。从上面这个例子中可以看到，你的程序可能会以三种完全不同的方式挂掉：
GC的安全性检查失败：一旦GC花费的时间占到98%以上的话，JVM就会宣告投降了： java.lang.OutOfMemoryError: GC overhead limit exceeded.
无法为下一个操作分配足够的内存：如果无法满足下一条指令所需要分配的内存的话，你会收到一条"java.lang.OutOfMemoryError: Java heap space" 的错误信息。
你可能也总结出来了，还有一种情况是你的内存已经紧张到连JVM创建一条OutOfMemoryError异常，填充堆栈信息，打印到屏幕上这点要求都满足不了了。这种情况UncaughtExceptionHandler会捕获到这个错误，而不再走通常的错误流程。这个处理器恰如其名，当线程由于某个异常快要挂掉的时候，它开始出来收场了。出现这种情况的话，JVM会找到线程对应的 UncaughtExceptionHandler,然后调用它的uncaughtException方法。
因此当你捕获到内存不足的异常并自以为已经胸有成竹时，请再多思考一下 .系统已经处于崩溃的边缘，你原认为你能依赖的信息很可能会消失或者改变。留给你的只有一脸茫然，正如我前面那12个小时中那样。
如果你已经耐心读到这了，我推荐你关注下我们的twitter帐号。我们每周都会发一些工作中碰到的一些性能调优的问题。