• <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>
            posts - 311, comments - 0, trackbacks - 0, articles - 0
              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

            (搬運工)對象池的弊端及優化

            Posted on 2012-07-26 15:16 點點滴滴 閱讀(905) 評論(0)  編輯 收藏 引用 所屬分類: 02 編程語言

            這幾天關于對象池的呼聲非常高,都源于這篇文章:http://bbs.9ria.com/thread-114544-1-1.html

            其實對象池并不適用于大多情況,并且使用不當,反而得到相反的結果,內存,CPU消耗更大。

            為什么呢?
            首先明確下,對象池是什么?
            對象池就是大量對象的集合。(你可以用數組保存它們)

             

            (黑色就是已經符合被移除條件的,非活動的;白色代表正在使用中的,活動的)


            接著,對象池有什么作用?
            當一定量的同類對象需要頻繁的出現又消失時,為了避免頻繁創建對象而造成效率低下,把符合消失條件的對象先不移除,等待下次使用時回收。

             

            問題來了
            1.”一定量的對象”, 說明這個對象池里面有超過20,50,100個對象,甚至更多。

            2.”為了避免頻繁創建”, 說明每間隔一定的時間就要重新創建一個對象,這間隔的時間也許是1秒,也許是每幀。

            3. 假如使用了對象池,既然要回收,那么就要遍歷這個對象池,遍歷出哪個對象是符合回收的。

             

            假設:如果每幀都要創建一個對象;如果使用對象池,那么每幀都要遍歷1次這個對象池,找出第一個符合回收的對象;如果這個對象池有100個對象,那么每幀循環100次;如果每幀需要創建n個對象,那么每幀循環n * 100次。(也許很快就找到符合回收的第一個對象,但常常并不會這樣)

             

            這個假如就說明了對象池也許會給CPU造成更大的壓力,還會引發什么問題,自己思考。

            (其實這個問題在我之前做的一個賽車游戲中就遇到過了,所有的障礙物都是放在池里面的回收利用的。地址:http://www.3366.com/flash/67959.shtml

             

             

            著名的Flixel引擎中FlxGroup就使用到了這個對象池技術,里面的members數組變量就相當于這個對象池容器了。它提供了一個recycle方法來回收對象,首先這個方法調用getFirstAvailable()來尋找members池中第一個被符合回收條件的對象(被kill),如果沒有找到再根據容器的最大容量來創建或返回對象。

            但是,它仍然沒有解決上述可能會造成頻繁遍歷的問題。

            我暫時想到三種方法來優化這個頻繁遍歷的問題。

             

            三種方法優化對象池
             

            1.把符合回收的對象重置在池的開頭。
            其實這里讓我想到了 緩存策略中基于雙鏈表的ALU實現,給每個資源都定義一個標識,標記使用的次數,當需要淘汰一個時,就用標識判斷最少使用的先被淘汰。

            但是這里對象池不存在使用次數,我們可以把已經淘汰的放在遍歷的開頭。

            也就是在向池returnObj()時,把obj對象unshift到池的開頭,等下次回收對象時再從池的開頭遍歷。

             

             

            2.設置兩個池,非活動池和活動池
            每次向池中申請一個對象時,就先訪問非活動池是否有被淘汰對象,有則返回第一個,并把它重新從非活動池返回到活動池中;如果沒有,則根據對象池容量大小是否重新創建或回收活動池中的。

            不過,這樣會麻煩很多,需要同時管理兩個數組和長度。

             

            3.給池子分類,分成不同類型的池,減少無用的遍歷。


            不過,還是要根據實際而行。

             

             

            不過實際項目中,我知道很多時候大多程序員都盡量不去使用對象池。
            求補充對象池弊端及優化或者替代方案。

            久久99精品国产99久久6男男| 思思久久好好热精品国产| www.久久精品| 女同久久| 综合久久精品色| 伊人久久国产免费观看视频| 久久久青草青青国产亚洲免观| 久久只有这里有精品4| 久久精品国产69国产精品亚洲| 香蕉久久永久视频| 久久久国产精品福利免费| 狠狠色丁香婷婷久久综合| 国产成人无码精品久久久免费| 久久久久久久久波多野高潮| 99久久免费国产精品| 久久人人爽人人爽人人AV东京热| 久久这里只有精品视频99| 国产高清美女一级a毛片久久w| 国产69精品久久久久9999APGF | 国产精品禁18久久久夂久| 蜜臀久久99精品久久久久久| 国产一久久香蕉国产线看观看| 精品一二三区久久aaa片| 久久www免费人成精品香蕉| 青青青国产精品国产精品久久久久| 中文字幕无码精品亚洲资源网久久| 精品久久久久久国产三级| 91精品婷婷国产综合久久| 国产精久久一区二区三区| 7国产欧美日韩综合天堂中文久久久久| 性欧美丰满熟妇XXXX性久久久| 中文字幕久久精品 | 69SEX久久精品国产麻豆| 麻豆成人久久精品二区三区免费| 99久久国产宗和精品1上映| 亚洲精品无码久久千人斩| 国产精品久久久久免费a∨| 久久精品人妻中文系列| 人妻精品久久无码区| 国产成人久久激情91| 午夜不卡888久久|