※ 引述《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 工具摸熟，常会有意想不到的妙用 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 75.177.186.231 ※ 文章网址: http://webptt.com/cn.aspx?n=bbs/java/M.1398461671.A.3B5.html ※ 编辑: AmosYang (75.177.186.231), 04/26/2014 05:40:07 我对 Android 不熟, 能否就「看到heap/free比例不对」多说一些? 感觉是个蛮有意思的方向, 感谢 orz 编辑改个 typo ※ 编辑: AmosYang (75.177.186.231), 04/26/2014 20:59:22