※ 引述《garywine1201 (那是啥)》之铭言： : 推 godfat:我倒觉得必然要观察 jvm, 毕竟实际上的 mem 是算在他头上 01/24 05 : 推 godfat:例如如果碰到 jvm memory leak, 我们 app 当然要避开 01/24 05 : 我当然同意这点 : 不过jvm的运作机制底下 : 并不允许程式以任何方式直接处理OS下的记忆体管理 : 而只能处理jvm下的记忆体管理 : 如此一来 : 若想要试着从程式解决jvm记忆体配置的问题 : 就好像你想试着从app解决OS记忆体分割的问题一样 : 都会因为权限不足 以及 你并不了解这个黑盒子的运作方式而作罢 : 不过幸运的是 java virture machine的规格书是完全公开的 : 可以在这边查阅 : http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html : 我也希望能够从这边找出一些端倪 : 若是可以 我会再回答看看这个问题 我是觉得不见得需要这麽深入到 jvm 里面，我想 jvm 有 memory leak 的状况 应该不会很多，不过 ruby 的 memory leak 状况我就看多了，通常会是某种 特定的程式写法会造成 memory leak. 此时也根本不必去了解 ruby interpreter 或 ruby virtual machine, 只要成功找出是哪段程式造成这个问题，然後随便 乱改写另一种写法，memory leak 很可能就会消失了... 当然会这麽说，是在不信任 java/ruby virtual machine 实作的假设下。 相信他绝对不会有问题的话，自然不必做到这一步。关於这点，我也相信 jvm 的问题绝对比 ruby 少很多很多 XDDD 另外其实我没看你给的实验连结，看到 sbrhsieh 大的回应才注意到该实验 是呼叫 java 里面的 method. 要观察 jvm 的动态，我建议还是用外部的方式 较为可靠，毕竟做到这本来就是在怀疑 jvm 本身，不应用被怀疑者来做观察。 （例如用 ps -o rss 来看） 再说实验里的 VisualCafe 2.5 on a Windows95 computer.... 好像有点年纪了 XDDDD updated: 对了，回到最初的问题，memory fragmentation 的状况，有时候是很难解决的。 这倒不见得一定是 jvm 的错，跟程式写法也很有关系，总之要尽量避免一次 大量地取用大量的记忆体，这样状况会比较好一点。跑好几个月发现记忆体 慢慢地在成长，我想虽然不是很理想，但应该还可接受，一年重开一次应该也还好。 -- 「行け！Loki！」（rocky ロッキー） －Gurumin ぐるみん 王子？ XD --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.135.28.18 ※ 编辑: godfat 来自: 220.135.28.18 (01/24 17:55)