眾所周知，java和c++不一樣，在java中，對象只能用new操作符在heap中分配，不可以象c++一樣在棧上分配。

一般來說，在堆上分配的效率要低于棧，。例如堆是全局的，在多線程程序中要使用鎖來進(jìn)行同步，不巧的是，絕大部分的java程序都是多線程的。另一方面，隨著對象的生成和銷毀，堆上會(huì)產(chǎn)生碎片，需要一個(gè)或多個(gè)freelist來維護(hù)，這樣也造成額外的開銷，以及空間利用的低效。

但這是一般c程序員理解的heap管理機(jī)制，也因此有c程序員指責(zé)java的內(nèi)存管理效率低下。其實(shí)在jvm的實(shí)現(xiàn)中，它會(huì)用自己的方式來管理堆，增強(qiáng)java的效率。以Hotspot為例，每個(gè)線程都會(huì)擁有一段自己的空間稱為TLAB(Thread Local Alloc Buffer)，這塊空間因?yàn)閷儆诰€程獨(dú)有，所以在其中分配對象不需要加鎖，其實(shí)和棧一樣，分配對象只要將一個(gè)指針增加sizeof(object)即可。如果對象太大超出了tlab的剩余空間，此時(shí)有多種選擇，
    在heap的share空間中分配，
    重新分配一塊tlab
    在old generation中分配
    觸發(fā)gc，釋放已有空間。
具體選擇何種方式由內(nèi)存的利用情況和jvm的內(nèi)存管理策略決定。由多個(gè)參數(shù)可以進(jìn)行調(diào)整。所以在絕大部分情況下（〉90%），jvm中對象的分配和棧一樣高效。

關(guān)于對象的釋放，就是java中著名的gc來負(fù)責(zé)了，關(guān)于gc的介紹多如牛毛，而且其中的方式和策略層出不窮，這片文章就不介紹了。

從上面的介紹可以看出，這種方式可以加速對象的分配，但對釋放不能作到象stack那樣高效，其實(shí)有很多對象只是生存期很短的臨時(shí)對象，如何識(shí)別這些對象并在tlab中更有效的釋放應(yīng)該是jvm可以進(jìn)一步優(yōu)化的方向。據(jù)我所知，jdk6的jvm已經(jīng)使用了相關(guān)的技術(shù)。