• <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年6月>
            2930311234
            567891011
            12131415161718
            19202122232425
            262728293012
            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ù)  更多評論
              
            亚洲伊人久久综合影院| 久久亚洲熟女cc98cm| 91精品婷婷国产综合久久| 亚洲综合精品香蕉久久网97| 国内精品久久久久久中文字幕 | 国产精品久久久久一区二区三区| 91精品国产综合久久四虎久久无码一级 | 成人国内精品久久久久影院| 99久久伊人精品综合观看| 亚洲色大成网站www久久九| 久久综合狠狠色综合伊人| 99精品国产免费久久久久久下载| 久久久青草青青亚洲国产免观| 四虎国产精品免费久久| 久久久久四虎国产精品| 色欲久久久天天天综合网精品| 激情综合色综合久久综合| 99精品国产综合久久久久五月天| 99久久精品国产毛片| 成人综合伊人五月婷久久| 亚洲精品乱码久久久久久中文字幕| 久久精品亚洲欧美日韩久久| 久久久亚洲欧洲日产国码二区| 久久久久亚洲AV成人网| 精品一区二区久久久久久久网站| 久久精品国产清自在天天线| 国产香蕉97碰碰久久人人| 久久精品一本到99热免费| 亚洲级αV无码毛片久久精品| 无码8090精品久久一区| 久久久久久亚洲精品不卡| 一本久久久久久久| 久久国产精品免费一区二区三区| 99久久国语露脸精品国产| 久久久无码精品亚洲日韩按摩| 久久综合精品国产二区无码| 亚洲色欲久久久综合网东京热| 久久亚洲美女精品国产精品| 久久精品国产男包| 日日躁夜夜躁狠狠久久AV| 午夜精品久久久久久99热|