※ 引述《sysc (和平时多准备)》之铭言： : ※ 引述《mgdesigner (魔法设计师)》之铭言： : : ~~~~~~~~~~~~~~~~~ : : 上面拆开来等於说： : : 1.产生一个新物件"xxx" : : 2.产生一参考 a，让a指向"xxx" : : ~~~~~~~~~~~ : : 这等於说： : : 1.产生一个新物件"bbb" : : 2.把a改指到"bbb" : : 但是"xxx"仍然存在喔，只是"xxx"目前没有被一个参考指到。 : : 你应该是说把"xxx"给清掉吧？ : : a=null;a= "bbb";这样？记得gc()一下，不过应该是没差很多。 : 我有注意到我写的简单代换String 的程式 : 我是用Timer 让字串一直代换 : 过了几个月後竟然会吃超多记忆体... : 虽然是没有变慢怎样的 : 重新执行也很正常 : 但是就是觉得怪怪的 这边有一些我对於java garbage collection与memory manaement行为的猜测 首先是gc函式只是建议jvm对记忆体进行清理 而非强迫 要清理与否仍然取决於jvm 这边有个短文 http://www.oreilly.com.tw/column_sleepless.php?id=j005 一般而言jvm会在某段时间过後对於记忆体进行清理 但其清理的是程式在jvm中占用的记忆体量 而非jvm在OS下的记忆体占用量 可以看一下这边对於gc()函式的实验 http://www.devdaily.com/java/edu/pj/pj010008/pj010008.shtml 摘录最後实验结果 free memory before creating array: 4054912 free memory after creating array: 3852496 free memory after running gc(): 4064184 在实验开始之前，jvm可用记忆体为4054912 这边指的是jvm在OS当中的占用量 实验开始之後，jvm的记忆体配置为3852496 但重新释放之後却使得记忆体可用为4064184 这边会发现jvm多吃了OS一些空间 因此对jvm进行free这个动作，并不会减少其耗用OS的资源能力 因为jvm是自行控管记忆体配置的 当程式开始使用记忆体时， jvm会判断所需的记忆体实作两个演算法 一是分配记忆体给该程式 二是判断需不需要预先再跟OS索取记忆体以及需索取多少记忆体配置 我想这是为了避免jvm会因为程式无预警的记忆体索取而导致out of memory 因此会预先对此行为进行准备 这个行为受限於jvm自己在记忆体占用预设设定的最小值与最大值 也可以用java -Xmx 与 -Xms 两个指令来指定 不过java -Xmx这种指令是用来指定单一程式的记忆体占用量而非jvm本身罢了 而这两个指令的上限值则取决於你的os愿意提供多少可用的资源给程式 因此，当程式需要日积月累的常驻 并且重复的宣告需求，如： a=null \\设定为空并等待垃圾处理 a="ccc"\\宣告新的字串并指定给a 那麽jvm是有可能持续的向OS索取记忆体的 因此这是你看到的 为什麽占用记忆体越来越大的原因 所以我认为 若你想了解的是 程式对记忆体的占用 我觉得应该依照上述这个实验 去观察程式对jvm的占用而不是jvm对OS的占用 你才能确定你的写法是不是占用的主因 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.64.235.79 我当然同意这点 不过jvm的运作机制底下 并不允许程式以任何方式直接处理OS下的记忆体管理 而只能处理jvm下的记忆体管理 如此一来 若想要试着从程式解决jvm记忆体配置的问题 就好像你想试着从app解决OS记忆体分割的问题一样 都会因为权限不足 以及 你并不了解这个黑盒子的运作方式而作罢 不过幸运的是 java virture machine的规格书是完全公开的 可以在这边查阅 http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html 我也希望能够从这边找出一些端倪 若是可以 我会再回答看看这个问题 ※ 编辑: garywine1201 来自: 61.64.235.79 (01/24 09:49)