將java物件記憶體釋放橋接到C 的delete上去，對於GC有什麼影響？

1樓：dwing

你的想法其實很多人都想過了, 但很少見到在自動管理記憶體的系統中提供手動delete, 最關鍵的原因就是這會把一門以記憶體安全當做最主要優勢打破了.

只要引入手動delete, 那麼所有的記憶體誤用都可能出現, 包括: 野指標(釋放後繼續訪問), 多次delete乙個指標. 解決這些問題對JVM來說即使在執行時也無能為力, 不用trace的方法根本無法判定要delete的物件是否有其它物件在引用.

開了這個口就像開啟了潘多拉魔盒, 帶來噩夢般的記憶體問題會毀了這門語言, 而且為了相容性還沒法在後續版本反悔.

這麼喜歡確定性釋放記憶體的話, 還是選C++或Rust吧.

2樓：圓胖腫

不知道他這麼做的目的何在

但是我已經知道，zgc在jdk 16的版本中已經實現了sub ms也就是1ms以內的gc暫停

所以我並不認為還有手動釋放記憶體的必要

zgc的作者par liden在昨天發了乙個blog，解釋了zgc的最新進展，可以看看

malloc.se/blog/zgc-jdk16另外，17估計shenandoah也會分代，所以gc在現在當下，應該已經不是什麼特別大的問題了

下乙個值得看的應該是panama

3樓：

有 Tracing GC 的情況下堆記憶體就是個大記憶體池，malloc 的效能是完全沒法和常規的堆記憶體分配比的，對於記憶體分配頻繁的程式來說可能會有明顯的效能下降，另外壓縮指標等功能很難做。小程式可能會有一定提公升（但更可能還不如直接用 Epsilon），較大的程式恐怕很難從中受益。