※ 引述《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)