• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 7  文章 - 57  trackbacks - 0
            <2011年3月>
            272812345
            6789101112
            13141516171819
            20212223242526
            272829303112
            3456789

            常用鏈接

            留言簿(3)

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

             

            Q1:為什么程序的數(shù)據(jù)需要放在堆、棧兩個不同(甚至更多)的地方?

             

            對于堆和棧中的數(shù)據(jù)內(nèi)容來說:

            棧:編譯器需知道數(shù)據(jù)內(nèi)容的生存周期、但是可以快速管理和分配棧內(nèi)存;

            堆:編譯器無需知道數(shù)據(jù)內(nèi)容的生存周期,保證靈活性、但是分配和回收內(nèi)存不如把數(shù)據(jù)放在棧中來得快;

             

            Q2:對象在其生命周期結(jié)束后經(jīng)歷什么步驟而后被釋放?銷毀機制具體是怎樣的?底層通過什么實現(xiàn)?

             

             

            當(dāng)程序執(zhí)行到一個塊or作用域(scope)的結(jié)尾,會自動清理其維護的棧中的內(nèi)存數(shù)據(jù)。

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

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

             

             

             

            對于在堆中,沒有被引用的對象。垃圾回收器會直接把他們占據(jù)的內(nèi)存空間釋放掉。

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

            會不會有一些不經(jīng)意的操作導(dǎo)致引用計數(shù)永遠不為零,然而用戶卻懵然不知呢?

            內(nèi)存泄漏真的可以在真正意義上得到避免嗎?

             

            Q3:垃圾回收機制究竟能干什么,不能干什么?究竟本質(zhì)是什么?

             

             

            垃圾回收機制原來只會對new出來的堆內(nèi)存起作用!!!

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

            1、You might not get garbage collected!

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

            還真是懶啊……

             

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

             

             

            這個垃圾回收機制還是回到回憶中去吧……(我沒吐槽最終幻想,真的沒有!)

             

             

            ClassName obj//局部對象,放在棧中(C++可以這樣,java不行)

            C++的好處:作用域結(jié)束,局部對象的destructor自動被調(diào)用,釋放棧中內(nèi)存;

             

            New出來的對象:

            //C++的壞處:不執(zhí)行delete的話,對象占用的內(nèi)存會一直賴在堆中。就讓內(nèi)存漏一會兒吧。

            //java的好處:不用顯式執(zhí)行,只要作用域結(jié)束,reference被清除,垃圾回收器就會自動回收堆中的內(nèi)存;

            而且,java兄還不讓你在棧中創(chuàng)建局部對象呢……

             

            Q3/1那究竟new操作發(fā)生的時候,java語言為用戶干了什么?new的操作也會對引用計數(shù)產(chǎn)生作用——例如初始化和創(chuàng)建嗎?垃圾回收器如何工作呢?

             

             

             

            相對于堆而言,在棧中釋放和分配內(nèi)存還是效率較高。這可能也是一些程序的數(shù)據(jù)放在棧中,一些放在堆中的原因之一吧?

             

             

            引用計數(shù)類似是一個對象中的成員;有東西引用對象,就增加1,當(dāng)有引用在棧中被釋放或者設(shè)為NULL,就減少1;發(fā)現(xiàn)引用計數(shù)為0,就證明這個對象已經(jīng)沒人要了……

            缺點:

            垃圾回收器要掃描整個對象列表,查找引用計數(shù)為0的對象;

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

            最悲催的是:

            JVM都不是通過這種機制實現(xiàn)垃圾回收滴……

             

             

            JVM是這么干的……

            逆向思維,不找死的,找活的!從一個引用出發(fā),遍歷其對象-樹(自己作的)。透過每一個在棧中或者在靜態(tài)區(qū)中保存的引用,以之為根節(jié)點,遍歷由他出發(fā)可以到達的對象節(jié)點。

            好處:

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

            解決兩個對象互相引用而導(dǎo)致引用計數(shù)恒不為0的問題;

             

             

            經(jīng)過上述處理,沒被找到的對象會被清理掉,但是會留下內(nèi)存碎片,浪費空間。所以……

            妙!

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

             

            然而,一直copycopy去需要有額外的堆內(nèi)存來保存copy的數(shù)據(jù),實際上copy發(fā)生的時候需要雙倍于被copy內(nèi)容的堆內(nèi)存同時可用。

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

            于是……

            JVM就把sweep-and-markstop-and-copy結(jié)合起來(thinking in java有詳述)

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

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

            根據(jù)引用來遍歷其對象-樹的操作開始執(zhí)行:

            一般來說,大對象是不會被copy的;

            小對象會被復(fù)制和重新管理,釋放內(nèi)存碎片;

            JVM在碎片多的時候進行stop-and-copy來整理碎片,騰出空間;在堆內(nèi)存足夠和碎片不多的情況下,則只執(zhí)行sweep-and-mark

             

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

             

            顯然是抄IBM大型機的外存管理嘛!數(shù)據(jù)集放在block中,被刪除的數(shù)據(jù)集的block標記為不可用,新建的數(shù)據(jù)集放在后面的block中。當(dāng)存儲空間不夠了,整理那些已經(jīng)存在又可用的數(shù)據(jù)集,存放在一片連續(xù)空間中,把碎片重新整理為可用內(nèi)存,真是……

            抄吧抄吧,不是罪……

             

             

            posted on 2011-03-04 20:49 ArthasLee 閱讀(838) 評論(1)  編輯 收藏 引用 所屬分類: 筆記和疑問

            FeedBack:
            # re: java學(xué)習(xí)筆記2——JVM和垃圾回收器 2011-03-21 00:28 陳梓瀚(vczh)
            garbage collection is only about memory的意思是說“GC只管內(nèi)存,不管句柄等資源”……  回復(fù)  更多評論
              
            久久综合狠狠综合久久| 亚洲国产精品成人久久| 99久久精品免费| 久久久中文字幕日本| 欧美激情精品久久久久久久| 久久亚洲色一区二区三区| 国产精品亚洲综合久久| 国产99精品久久| 亚洲婷婷国产精品电影人久久| 久久99热精品| 麻豆久久| 久久99中文字幕久久| 麻豆精品久久久久久久99蜜桃| 九九99精品久久久久久| 久久精品国产亚洲AV香蕉| 99久久亚洲综合精品成人| 亚洲中文字幕无码久久综合网 | 国产免费久久久久久无码| 久久久www免费人成精品| 99久久国产免费福利| 无码伊人66久久大杳蕉网站谷歌| 久久精品亚洲精品国产欧美| 国产精品一久久香蕉产线看| 久久99热这里只频精品6| 国产日韩久久免费影院| 99久久99这里只有免费的精品| 国产A级毛片久久久精品毛片| 国产成人精品久久亚洲| 久久精品国产影库免费看| 日产精品久久久久久久| 久久久国产乱子伦精品作者| 精品国产乱码久久久久久呢| 国产精品99久久久精品无码 | 99久久夜色精品国产网站| 精品综合久久久久久97超人| 久久婷婷激情综合色综合俺也去| AV无码久久久久不卡蜜桃| 一本久久a久久精品亚洲| 久久亚洲sm情趣捆绑调教| 精品国产乱码久久久久久人妻| 久久人做人爽一区二区三区|