垃圾收集器vs池

我正在運行涉及創建樹的模擬。我的樹有2/3到7/8的分支因子。垃圾收集器vs池

每次我需要擴展它，我爲孩子分配一個數組。很多時候，我通過設置一個根的子樹作爲一棵樹的新樹（所以我的樹的其餘部分變成垃圾）。我想知道是否讓垃圾收集器做他的工作更好（我建議「當我更改樹根時，他開始收集System.gc（）），或實現我自己的TreeNodes池，當我更改根目錄時，請回收所有現在無用的節點。

答案可以理解爲：是非常優化的Android垃圾收集器，還是限制對象的創建/銷燬，即使這很耗時？（我需要遍歷所有樹，並追加每個無用的節點堆棧爲我的池）

我讀到，Android GC不是「進化」（它基本上運行時，你有低內存。）此外，我不知道是否刪除每一個引用樹的根會讓gc垃圾一次收集所有的樹，或者它只會gc節點，然後該節點的子節點再次通過，依此類推。

來源

2012-02-10 Makers_F

首先，你需要了解GC是否是ev爲你擔心。所以用-verbosegc運行你的應用程序。如果您的GC報告性能問題或內存增加，您可以擔心它。否則將它從你要做的事情中排除。

GC工作在世代。基本上你的分配分成幾代。當你的應用程序加載所有的分配在第0代時。並且隨着應用程序的進展，你的分配被放入第1代和第2代。當它運行時，GC不會在第0代時非常頻繁地運行，就像在第1代時一樣。同樣，更常見於第1代，就像第2代一樣。這是在假設您在加載時分配的對象不需要像後面創建的對象那樣經常釋放的情況下完成的。

從http://chaoticjava.com/posts/how-does-garbage-collection-work/

在任何應用中有趣的報價，對象可以根據自己的生命線進行分類。
某些對象是短命的，例如大多數本地變量，而其中一些是長期存在的，如應用程序的主幹。
有關代世代垃圾收集的想法是的理解是，在應用程序的生命週期中，大多數實例化對象都是短命的，並且在那裏存在長壽命對象與短壽命之間的很少連接對象。

來源

2012-02-10 11:34:41 Siddharth

我已經閱讀過那篇文章（是的，它真的很有趣），但我正在專門討論android gc。在我的應用程序中，它經常運行（logcat打印GC_Concurrent，空閒x％y/z，採用5ms + 6ms）。在我的應用程序不是一個性能問題（它仍然運行60fps），我最想知道的最佳做法**爲Android（移動）**平臺（文章是從2008年，所以我不認爲它可以應用在android gc上，另外我認爲android gc在以後的版本中有很大的改變） – 2012-02-10 11:43:09

實現你自己的treenodes實際上是解決它的一個有趣的方法。問題是你在這裏測量什麼。如果你不衡量性能，那麼內存利用率？除非你知道你在這裏測量什麼，否則你不知道可以給你帶來什麼好處。GC是否佔用了太多時間，難道你沒有得到你期望從你的應用程序的迴應？它佔用了太多的內存嗎？你認爲通過編寫自己的游泳池，你會提高gc嗎？如果gc是你的問題，那麼你應該測量gc耗盡多少時間，然後寫下你的池子，然後再測量一次。你測量了嗎？ – Siddharth 2012-02-10 11:56:11

我已經有了一個通用池，因此爲我的TreeNode編寫一個池是在請求TreeNode並遍歷樹以在回收TreeNode時回收所有子節點時更新爲正確值的問題。內存現在不會出現問題（我還沒有嘗試過很長時間的模擬，因爲我的代碼中仍然有一些bug需要解決），而且cpu也不算太多，但是因爲我在移動設備上運行，我的代碼效率越高，電池消耗越少，使用戶浪費，而Android對這個問題也很殘酷（它清楚地顯示了一個應用消耗多少電量）。不，我不測量..（好點） – 2012-02-10 12:10:32

垃圾收集器vs池

回答

相關問題