• <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 點點滴滴 閱讀(900) 評論(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.給池子分類,分成不同類型的池,減少無用的遍歷。


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

             

             

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

            久久天天躁狠狠躁夜夜2020一| 无码任你躁久久久久久老妇App| 日本强好片久久久久久AAA| 久久精品极品盛宴观看| 久久精品久久久久观看99水蜜桃| 精品久久人人爽天天玩人人妻| 色综合久久综合中文综合网| 成人午夜精品久久久久久久小说| 亚洲国产一成久久精品国产成人综合 | 久久久久久狠狠丁香| 无夜精品久久久久久| 久久精品中文字幕无码绿巨人| 国产99久久久久久免费看| 久久久国产打桩机| 久久se精品一区二区影院| 久久偷看各类wc女厕嘘嘘| 久久久艹| 国产精品免费久久久久电影网| 亚洲国产精品无码久久久秋霞2 | 精品久久久久久无码人妻热| 伊人久久综合无码成人网| 久久久久久青草大香综合精品| 2021久久国自产拍精品| 久久人人爽人人爽人人片av麻烦 | 精品熟女少妇a∨免费久久| 亚洲AV伊人久久青青草原| 久久免费小视频| 成人国内精品久久久久影院| 亚洲国产另类久久久精品黑人| 性高朝久久久久久久久久| 精品久久久久国产免费 | 久久只这里是精品66| 久久久久国产精品三级网| 久久久久国产一级毛片高清版| 99久久婷婷国产综合亚洲| 亚洲国产另类久久久精品小说| 久久只有这里有精品4| 久久这里只有精品首页| 亚洲中文字幕无码一久久区| 午夜人妻久久久久久久久| 久久99国产综合精品|