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


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

             

             

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

            久久久久国色AV免费观看| 国产亚洲精久久久久久无码| 久久国产V一级毛多内射| 欧美日韩成人精品久久久免费看 | 久久偷看各类wc女厕嘘嘘| 97超级碰碰碰久久久久| 久久精品无码一区二区三区免费| 久久夜色精品国产噜噜亚洲a| 久久亚洲国产成人精品性色| 久久精品无码一区二区app| 少妇久久久久久被弄高潮| 久久人人超碰精品CAOPOREN | 麻豆精品久久精品色综合| 久久天天躁狠狠躁夜夜av浪潮 | 久久精品中文字幕无码绿巨人| 久久精品国产精品亚洲精品| 7777精品伊人久久久大香线蕉 | 色青青草原桃花久久综合| 久久96国产精品久久久| 亚洲中文字幕无码久久2020| 精品无码久久久久久久动漫 | 久久九九免费高清视频 | 久久精品成人免费网站| 亚洲中文字幕久久精品无码喷水| 99久久精品免费国产大片| 精品国产乱码久久久久久1区2区| 国产99久久久国产精品小说| 国产女人aaa级久久久级| 欧美伊香蕉久久综合类网站| 久久午夜羞羞影院免费观看| 亚洲中文字幕无码久久2020| 思思久久精品在热线热| 免费无码国产欧美久久18| 欧美精品丝袜久久久中文字幕 | 久久这里有精品| 亚洲精品国产自在久久| 思思久久99热免费精品6| 国产一区二区久久久| 久久婷婷五月综合国产尤物app| 亚洲国产精品综合久久网络| 热综合一本伊人久久精品|