其實這篇文章幾個月以前已經發布到簡書博客裏了,可是文章發佈以後,有人反饋了一些問題,而我對於這篇文章也有刪改增補的想法,因此這篇文章會是原文的簡潔加強版python
這篇文章講的是Java的JVM的垃圾回收機制,可是Android使用的虛擬機是Dalvik或者ART,那麼下面講的垃圾回收機制是否適用於Android呢?android
答案是,Yes,是能夠類比的。算法
(增補)
文章末尾有人提出了質疑: JVM 的內存模型和 Android 虛擬機是區別的?網絡
答案:是的,Android基於寄存器,jvm基於堆棧,本文其實避免了這樣的探討,那是由於在邏輯上它們其實沒有太大區別,Android做爲移動操做系統基於寄存器,能夠極大提升它的訪存速度,從而提升它的程序運行速度,堆棧訪存就慢些。這是最大的區別,在這裏作出說明。多線程
其餘的問題我也在評論裏作出了迴應,有任何問題均可以在下面探討,若是本文有重大漏洞,我會卸載勘誤
一欄中,你們能夠關注一下。jvm
做爲Android工程師,我看過不少關於Android內存泄漏的相關優化的文章,其中大部分都是告訴你該怎麼作,作哪些,列一些具體的措施。不多解釋爲何要這麼作,即便解釋,也只是一筆帶過。post
今天,我就之內存回收爲突破口,向你們解釋從底層到上層,是如何配合完成內存回收的。咱們就從Java程序運行時的內存區域開始吧。優化
運行時內存區域,指的是當你的程序被JVM加載進來執行的時候,內存是怎麼分配的。spa
下面,就是Java程序運行時的內存模型操作系統
執行引擎:哎呀臥槽,剛纔執行到哪一步來着?
程序計數器:傻逼。複製代碼
其實上面那五個區域,和這篇文章關係最緊密的時堆和虛擬機棧中的局部變量表(也就是咱們常說的棧),棧中主要保存了對象的引用,堆中保存了實際的對象,所以,實際上堆佔了整個程序運行內存的大頭,所以,內存回收就發生在堆中。
當程序運行時,而後躲在暗處的那個飢渴難耐端的垃圾回收機制(GC)就立刻跳出來了。虎視眈眈的盯着堆中的對象,專門找那些「落單」的對象....
那麼,GC是怎麼知道哪一個對象「落單」了呢,答案是GC Roots引用鏈。
關於GC引用鏈不管怎麼說,都很難想象,那不要緊,我來畫一畫就行了。
當那些待回收的對象被標記以後,GC就會開始回收對象釋放內存。GC的回收算法有不少種,通常虛擬機配合多種內存回收算法來實現內存的高效回收,可是這些和咱們其實關係不大,所以能夠略過。
好了,咱們終於把Java內存回收的機理講完了,那麼內存優化背後的機理也基本被咱們扒開了:
不少Android優化場景,基本圍繞了一個點:
因此Java內存優化一個最根本的準則,就是努力使你的程序適配Java的GC機制。
最近下定決心要涉足新領域,所以給本身定下目標,從這一篇開始,要系統的概括本身所學的知識技術以及積攢的經驗,以文章的方式產出。內容主要以Java+Android相關爲主,以JS+React-native次之,而後是一些基於python的有意思的項目(是大學裏寫的,會從新整理)。
你們放心,個人文章會保證一向的簡單友好,至少同一個層次的知識,個人文章能比別人更加友好,我有這樣的信心。
回到這篇文章自己,其實在從新整理的時候,我已經發現最近掘金上已經有人把Android優化整理了一個系列文章,我以爲寫的很不錯,在這裏也能夠推薦給你們@anly_jun: android優化系列。
固然,若是你比較欣賞個人文章風格,歡迎關注我,我會在保證文章質量的前提下,提升寫做速度的。
共勉
暫無
《深刻理解Java虛擬機》