※ 引述《PsMonkey (痞子军团团长)》之铭言：
: 在花了一天对付另一个 [Heisenbug]：每当我快抓到原因，它就会变了样；
闲聊瞎扯一下 :>
前几个月正好处理过一个类似的情形: 一个 multithreaded 的 .NET 程式不定时的
炸 OOM exception
对付陈宫，只能用箭；对付 Heisenbug, 除了 process dump analysis 外
大概没什么好办法
参考
* http://blogs.msdn.com/b/dotnet/archive/2009/10/15/automatically-capturing-a-dump-when-a-process-crashes.aspx
* http://blogs.msdn.com/b/pranavwagh/archive/2009/06/09/how-to-take-the-dump-for-a-process-which-crashes-randomly.aspx
* http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
* http://stackoverflow.com/questions/1134048/generating-net-crash-dumps-automatically
* google jvm crash dump
通常来说， OOM 算是好解的问题，因为 OOM 多半来自 memory leak + loop
是故 heap 里多半会散布著大量相似的物件, 只要能辨认这些物件
通常反推回程式码里的问题点就没那么难
然而，有另一型的 OOM, 很久之前有稍微提过, 是属于 architectural 的问题,
就很难解 :( 因为 OutOfMemory 有时指的不是“内存的量不够”
而是“没有连续够大块的内存”
该案例里，就是大量地创造、释放大型物件 ( 大型物件会取在 .NET gen 2 heap ) 上
使得 gen 2 heap 的“连续可用空间”变得支离破碎,
而“可用空间总量”看起来还剩很多
打个比方，就像一立方公尺的木条跟一立方公尺的木屑都是一立方公尺的木料
但后者没办法拿来盖房子; 在这种情形下，不管是 .NET 还是 Java,
都只会炸 OOM, 不知道为什么不能设计成改炸 OutOfContinuousMemory 这种的...
最近几期的 MSDN 杂志里提到最新的 .NET GC 应该可以避免 fragmentation 发生
不知道最新的 Java 8 在这方面有没有相对应的改进
这种 OOM 就很难解…最快的解法就是装傻... :D
总结: 写 server 程式时，若能把该平台上的 debug 工具摸熟，常会有意想不到的妙用