Q1：為什么程序的數據需要放在堆、棧兩個不同（甚至更多）的地方？

對于堆和棧中的數據內容來說：

棧：編譯器需知道數據內容的生存周期、但是可以快速管理和分配棧內存；

堆：編譯器無需知道數據內容的生存周期，保證靈活性、但是分配和回收內存不如把數據放在棧中來得快；

Q2：對象在其生命周期結束后經歷什么步驟而后被釋放？銷毀機制具體是怎樣的？底層通過什么實現？

當程序執行到一個塊or作用域（scope）的結尾，會自動清理其維護的棧中的內存數據。

于是，如果保存在棧中的唯一reference掛掉了，就意味著再沒有辦法可以操作其原先引用的對象了。

但是保存在堆中的對象在這時候還沒有被清理掉。

對于在堆中，沒有被引用的對象。垃圾回收器會直接把他們占據的內存空間釋放掉。

真的如書中所說，這種機制滴水不漏嗎？會不會有陷阱？

會不會有一些不經意的操作導致引用計數永遠不為零，然而用戶卻懵然不知呢？

內存泄漏真的可以在真正意義上得到避免嗎？

Q3：垃圾回收機制究竟能干什么，不能干什么？究竟本質是什么？

垃圾回收機制原來只會對new出來的堆內存起作用！！！

萬一不是new出來的，那還是得人工回收……

1、You might not get garbage collected！

哎……這樣的垃圾回收機制啊……

還真是懶啊……

總之就是，垃圾回收機制只會回收對象在堆中的內存，但究竟這個對象的操作曾經干了什么，有沒有“歷史遺留問題”，java是一概不管的……

這個垃圾回收機制還是回到回憶中去吧……（我沒吐槽最終幻想，真的沒有！）

ClassName obj；//局部對象，放在棧中（C++可以這樣，java不行）

C++的好處：作用域結束，局部對象的destructor自動被調用，釋放棧中內存；

New出來的對象：

//C++的壞處：不執行delete的話，對象占用的內存會一直賴在堆中。就讓內存漏一會兒吧。

//java的好處：不用顯式執行，只要作用域結束，reference被清除，垃圾回收器就會自動回收堆中的內存；

而且，java兄還不讓你在棧中創建局部對象呢……

Q3/1：那究竟new操作發生的時候，java語言為用戶干了什么？new的操作也會對引用計數產生作用——例如初始化和創建嗎？垃圾回收器如何工作呢？

相對于堆而言，在棧中釋放和分配內存還是效率較高。這可能也是一些程序的數據放在棧中，一些放在堆中的原因之一吧？

引用計數類似是一個對象中的成員；有東西引用對象，就增加1，當有引用在棧中被釋放或者設為NULL，就減少1；發現引用計數為0，就證明這個對象已經沒人要了……

缺點：

垃圾回收器要掃描整個對象列表，查找引用計數為0的對象；

如果有兩個對象碰巧相互引用了彼此，那這兩個對象的引用計數就用不為零，即使沒人要也不會被清除掉；

最悲催的是：

JVM都不是通過這種機制實現垃圾回收滴……

JVM是這么干的……

逆向思維，不找死的，找活的！從一個引用出發，遍歷其對象-樹（自己作的）。透過每一個在棧中或者在靜態區中保存的引用，以之為根節點，遍歷由他出發可以到達的對象節點。

好處：

不用遍歷所有堆中的對象。

解決兩個對象互相引用而導致引用計數恒不為0的問題；

經過上述處理，沒被找到的對象會被清理掉，但是會留下內存碎片，浪費空間。所以……

妙！

把程序停止下來，把活動的對象copy到新的堆內存，連續存放，這樣就騰出了那些原先成為碎片的空間。

然而，一直copy來copy去需要有額外的堆內存來保存copy的數據，實際上copy發生的時候需要雙倍于被copy內容的堆內存同時可用。

其次，copy也需要時空開銷……

于是……

JVM就把sweep-and-mark和stop-and-copy結合起來（thinking in java有詳述）

大對象占用一個block，每個block有一個generation count作為其可用與否的標記。

一些小對象放在一個block里；

根據引用來遍歷其對象-樹的操作開始執行：

一般來說，大對象是不會被copy的；

小對象會被復制和重新管理，釋放內存碎片；

JVM在碎片多的時候進行stop-and-copy來整理碎片，騰出空間；在堆內存足夠和碎片不多的情況下，則只執行sweep-and-mark。

在這樣的垃圾回收機制下，只要是new出來的東西，真的都能回收了。某程度上還真是滴水不漏啊……

顯然是抄IBM大型機的外存管理嘛！數據集放在block中，被刪除的數據集的block標記為不可用，新建的數據集放在后面的block中。當存儲空間不夠了，整理那些已經存在又可用的數據集，存放在一片連續空間中，把碎片重新整理為可用內存，真是……

抄吧抄吧，不是罪……