• <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ù)據需要放在堆、棧兩個不同(甚至更多)的地方?

             

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

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

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

             

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

             

             

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

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

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

             

             

             

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

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

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

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

             

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

             

             

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

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

            1、You might not get garbage collected!

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

            還真是懶啊……

             

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

             

             

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

             

             

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

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

             

            New出來的對象:

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

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

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

             

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

             

             

             

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

             

             

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

            缺點:

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

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

            最悲催的是:

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

             

             

            JVM是這么干的……

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

            好處:

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

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

             

             

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

            妙!

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

             

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

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

            于是……

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

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

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

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

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

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

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

             

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

             

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

            抄吧抄吧,不是罪……

             

             

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

            FeedBack:
            # re: java學習筆記2——JVM和垃圾回收器 2011-03-21 00:28 陳梓瀚(vczh)
            garbage collection is only about memory的意思是說“GC只管內存,不管句柄等資源”……  回復  更多評論
              
            狠狠色综合久久久久尤物| 久久久精品国产免大香伊| .精品久久久麻豆国产精品| 成人国内精品久久久久影院| 97久久久精品综合88久久| 久久久久亚洲精品男人的天堂| 思思久久99热只有频精品66| 亚洲精品乱码久久久久久久久久久久| 麻豆成人久久精品二区三区免费 | 久久免费线看线看| 久久人人爽人人澡人人高潮AV| 久久精品无码一区二区WWW| 久久青青草原国产精品免费| 久久强奷乱码老熟女网站| 亚洲国产成人久久精品影视 | 青青草原综合久久| 人妻丰满AV无码久久不卡| 久久久久这里只有精品| 精品久久777| 996久久国产精品线观看| 无码任你躁久久久久久老妇| 久久91精品国产91久久小草| 一本久道久久综合狠狠爱| 久久男人AV资源网站| 国产巨作麻豆欧美亚洲综合久久| 久久亚洲精品无码AV红樱桃| 国产精品久久久久蜜芽| 久久国产成人午夜aⅴ影院| 久久伊人精品青青草原高清| 久久久国产乱子伦精品作者| 天天做夜夜做久久做狠狠| 色婷婷久久久SWAG精品| 天天做夜夜做久久做狠狠| 亚洲午夜无码AV毛片久久| 久久婷婷色综合一区二区| 伊人情人综合成人久久网小说| 合区精品久久久中文字幕一区| 久久99热这里只有精品国产| 欧美激情精品久久久久久久| 久久久精品久久久久久| 一级a性色生活片久久无|