對象池模式的變形

本文大部分內(nèi)容翻譯至《Pro Design Pattern In Swift》By Adam Freeman，一些地方做了些許修改，并將代碼升級到了Swift2.0,翻譯不當(dāng)之處望多包涵。

對象池模式的變形

這里我們將介紹如何改變對象池模式來滿足不同的需求。

理解對象池模式的變種

實現(xiàn)對象池包含四種策略：

  • 對象的創(chuàng)建策略
  • 對象的重用策略
  • 空對象池策略
  • 對象的分配策略

通過改變這些策略，可以滿足你需要的對象池的合適的實現(xiàn)。

理解對象的創(chuàng)建策略

在上一章中，我們使用了饑餓策略來創(chuàng)建對象，就是指對象在使用之前就已經(jīng)被創(chuàng)建了出來。

Library.swift

...
    private init(stockLevel:Int) {
        books = [Book]()
        
        for count in 1 ... stockLevel {
            books.append(Book(author: "Dickens, Charles", title: "Hard Times",
            stock: count))
      }
        pool = Pool<Book>(items:books)
    }
...

這種策略適用于當(dāng)面對代表真實世界資源的對象時，因為對象的個數(shù)事先就已經(jīng)非常的清楚。但是這種策略的缺點也顯而易見，那就是即使是沒有任何需求的時候，所有的對象也都將被創(chuàng)建和配置。

另一種策略就是延遲創(chuàng)建策略,就是只有當(dāng)有需求時對象才被創(chuàng)建。這里我們創(chuàng)建一個BookSeller類：

BookSerller.swift

import Foundation

class BookSeller {
    class func buyBook(author:String, title:String, stockNumber:Int) -> Book {
        return Book(author: author, title: title, stock: stockNumber)
    }
}

BookSeller類定義了一個類方法用來創(chuàng)建Book對象。下面我們將修改Pool類來支持延遲對象的創(chuàng)建直到有需求發(fā)生。

Pool.swift

import Foundation

class Pool<T> {
    private var data = [T]()
    private let queue = dispatch_queue_create("arrayQ", DISPATCH_QUEUE_SERIAL)
    private let semaphore:dispatch_semaphore_t
    private var itemCount = 0
    private let maxItemCount:Int
    private let itemFactory: () -> T
    
    init(maxItemCount:Int, factory:() -> T) {
        self.itemFactory = factory
        self.maxItemCount = maxItemCount
        semaphore = dispatch_semaphore_create(maxItemCount)
    }
    
    func getFromPool() -> T? {
       var result:T?
    
       if (dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER) == 0) {
           dispatch_sync(queue, { () -> Void in
        
            if (self.data.count == 0 && self.itemCount < self.maxItemCount) {
                result = self.itemFactory()
                self.itemCount++
            } else {
                result = self.data.removeAtIndex(0);
            }
        })
        
        }
        return result
    }
    
    func returnToPool(item:T) {
        dispatch_async(queue) { () -> Void in
           self.data.append(item)
           dispatch_semaphore_signal(self.semaphore)
        }
        
    }
    
    func processPoolItems(callback:[T] -> Void) {
        dispatch_barrier_sync(queue, {() in
            callback(self.data)
        })
    }
}

我們改變了Pool類的初始化方法，它接收一個用來創(chuàng)建對象的閉包和一個代表對象池大小的Int類型值。

另一個改變是我們增加了一個方法processPoolItems用來記錄借出信息。因為在原來代碼中，對象的創(chuàng)建是由Library類中來實現(xiàn)，所以Library中可以保持對Book數(shù)組對引用。這里我們?yōu)榱藢崿F(xiàn)使用了回調(diào)方法來操作Book數(shù)組，而dispatch_barrier_sync保證了隊列中所有任務(wù)完成后才會執(zhí)行回調(diào)方法。
最后我們修改Library 類實現(xiàn)延遲創(chuàng)建：

Library.swift

import Foundation

class Library {

    private let pool:Pool<Book>
    static let sharedInstance = Library(stockLevel: 200)
    
    private init(stockLevel:Int) {
        var stockId = 1
        pool = Pool<Book>(maxItemCount: stockLevel, factory: { () -> Book in
            return BookSeller.buyBook("Dickens, Charles",
                title: "Hard Times", stockNumber: stockId++)
        })
    }
    
   
    func checkoutBook(reader:String) -> Book? {
        let book = pool.getFromPool()
        book?.reader = reader
        book?.checkoutCount++
        return book
    }
    
    func returnBook(book:Book) {
        book.reader = nil
        pool.returnToPool(book)
    }
    
    func printReport() {
        pool.processPoolItems { (books) -> Void in
            for book in books {
                print("...Book#\(book.stockNumber)...")
                print("Checked out \(book.checkoutCount) times")
                
                if (book.reader != nil) {
                    print("Checked out to \(book.reader!)")
                } else {
                    print("In stock")
                }
            }

        
        }
    }
}

如果執(zhí)行程序，我們也許會得到以下的結(jié)果：

Starting...
All blocks complete
...Book#7...
Checked out 2 times
In stock
...Book#4...
Checked out 4 times
In stock
...Book#13...
Checked out 1 times
In stock
...Book#1...
Checked out 1 times
In stock
...Book#2...
Checked out 1 times
In stock
...Book#3...
Checked out 1 times
In stock
...Book#9...
Checked out 1 times
In stock
...Book#10...
Checked out 1 times
In stock
...Book#8...
Checked out 1 times
In stock
...Book#5...
Checked out 2 times
In stock
...Book#11...
Checked out 1 times
In stock
...Book#6...
Checked out 3 times
In stock
...Book#12...
Checked out 1 times
In stock
There are 13 books in the pool

因為我們增加了一個隨機時間等待的緣故，Book的確切數(shù)字每次都會不同。最糟糕的情況是20本書全都被創(chuàng)建，那就意味著圖書館對于200本書的購買總額估計過高。如果我們這里使用饑餓策略，那么200本的副本都將被創(chuàng)建，延遲策略的優(yōu)點就在于此。

理解對象的重用策略

對象池模式的性質(zhì)意味著池中的對象會重復(fù)的分配給請求對象，這樣就導(dǎo)致了一個風(fēng)險那就是對象被歸還的時候處在一個糟糕的狀態(tài)。在現(xiàn)實世界的圖書館中，這就好比歸還的書出現(xiàn)了撕裂或者缺頁。在軟件中，就意味著對象出現(xiàn)了不一致的狀態(tài)或者遭遇了不可恢復(fù)的錯誤。

最簡單的解決方法是信任策略，這就是你相信歸還的對象都會是一個可重用的狀態(tài)。對象池中管理的Book對象目前還沒發(fā)生這種問題是因為它們幾乎沒提供任何可變的公開狀態(tài)。

另一種就是不信任策略，當(dāng)對象被歸還之前做一個檢查來確保它們都是可重用的狀態(tài)。那些不能重用的對象都將被丟棄。

Caution:不信任策略只能用于那些有能力替代對象的對象池。如果沒有能力去替代對象，那么對象池最終會耗盡。

我們將改變Book對象的使用方法來實現(xiàn)它們只能被借出特定的次數(shù)，反應(yīng)了一個事實那就是書會承擔(dān)磨損和消耗直到?jīng)]辦法在使用。下面我們定義一個PoolItem的協(xié)議。

PoolItem.swift

import Foundation

@objc protocol PoolItem {
    var canReuse:Bool {get}
}

PoolItem 協(xié)議定義了一個只讀屬性canReuse，當(dāng)對象被歸還時我們將檢查這個屬性如果是false該對象將被遺棄。

Tip:注意到我們使用了@objc標(biāo)注，這將支持對象向下轉(zhuǎn)型成PoolItem，讓我們能在Pool中讀取canReuse屬性。

接下來修改Pool類：

Pool.swift

import Foundation

class Pool<T> {
    private var data = [T]()
    private let queue = dispatch_queue_create("arrayQ", DISPATCH_QUEUE_SERIAL)
    private let semaphore:dispatch_semaphore_t
    private var itemCount = 0
    private let maxItemCount:Int
    private let itemFactory: () -> T
    
    init(maxItemCount:Int, factory:() -> T) {
        self.itemFactory = factory
        self.maxItemCount = maxItemCount
        semaphore = dispatch_semaphore_create(maxItemCount)
    }
    
    func getFromPool() -> T? {
       var result:T?
    
       if (dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER) == 0) {
           dispatch_sync(queue, { () -> Void in
        
            if (self.data.count == 0 && self.itemCount < self.maxItemCount) {
                result = self.itemFactory()
                self.itemCount++
            } else {
                result = self.data.removeAtIndex(0);
            }
        })
        
        }
        return result
    }
    
    func returnToPool(item:T) {
        dispatch_async(queue) { () -> Void in
           let pitem = item as AnyObject as? PoolItem;
           if (pitem == nil || pitem!.canReuse) {
              self.data.append(item)
              dispatch_semaphore_signal(self.semaphore)
           }
        }
        
    }
    
    func processPoolItems(callback:[T] -> Void) {
        dispatch_barrier_sync(queue, {() in
            callback(self.data)
        })
    }
}

因為不想限制池中管理對象的范圍，所以這里只檢查那些實現(xiàn)了PoolItem協(xié)議的對象是否能重用。

...
 let pitem = item as? PoolItem
 if (pitem == nil || pitem!.canReuse) {
       self.data.append(item)
       dispatch_semaphore_signal(self.semaphore)
 }
...

接著我們讓Book類實現(xiàn)PoolItem協(xié)議：

import Foundation
class Book : PoolItem {
    
    let author:String
    let title:String
    let stockNumber:Int
    var reader:String?
    var checkoutCount = 0
    
    init(author:String, title:String, stock:Int) {
        self.author = author
        self.title = title
        self.stockNumber = stock
    }
    
   var canReuse:Bool {
        get {
            let reusable = checkoutCount < 5
            if (!reusable) {
                print("Eject: Book#\(self.stockNumber)")
            }
            return reusable
        }
    }
}

為了測試這個策略，我們必須修改圖書館的書的總數(shù)，以便讓讀者借到臨界線。

Library.swift

...
   static let sharedInstance = Library(stockLevel: 5)
...

運行程序，得到下面結(jié)果：

Starting...
Eject: Book#5
Eject: Book#4
All blocks complete
...Book#2...
Checked out 3 times
In stock
...Book#1...
Checked out 3 times
In stock
...Book#3...
Checked out 4 times
In stock
There are 3 books in the pool

理解空對象池策略

空對象池策略，顯而易見，就是對象池空了時發(fā)生請求時該怎么辦。最簡單的方法就是我們上面所用的，請求的線程一直等待直到有對象被歸還。

阻塞策略雖然簡單，但是如果池中的對象的總數(shù)和需求總數(shù)不協(xié)調(diào)的話就會拖慢應(yīng)用程序。 如果阻塞策略和和前面提到的不信任管理策略結(jié)合在一起的話還會造成應(yīng)用程序死鎖。

我們做如下修改：

main.swift

import Foundation
var queue = dispatch_queue_create("workQ", DISPATCH_QUEUE_CONCURRENT)
var group = dispatch_group_create()
print("Starting...")
for i in 1 ... 35{
    dispatch_group_async(group, queue, {() in
        var book = Library.sharedInstance.checkoutBook("reader#\(i)")
        if (book != nil) {
            NSThread.sleepForTimeInterval(Double(rand() % 2))
            Library.sharedInstance.returnBook(book!)
        }
    })
}

dispatch_group_wait(group, DISPATCH_TIME_FOREVER)

print("All blocks complete")

Library.sharedInstance.printReport()

我們將借書的請求從20次增加到了35次，很顯然我們會得到下面的結(jié)果：

Starting...
Eject: Book#4
Eject: Book#5
Eject: Book#3
Eject: Book#2
Eject: Book#1

實現(xiàn)請求失敗策略

請求失敗策略通過將責(zé)任轉(zhuǎn)移給請求對象的組件來處理空對象池的情況。組件必須指定在請求失敗之前的等待時間。

Pool.swift

...
    func getFromPool(maxWaitSeconds:Int = 5) -> T? {
       var result:T?
        
       let waitTime = (maxWaitSeconds == -1) ? DISPATCH_TIME_FOREVER : dispatch_time(DISPATCH_TIME_NOW, (Int64(maxWaitSeconds) * Int64(NSEC_PER_SEC)))
    
       if (dispatch_semaphore_wait(semaphore, waitTime) == 0) {
           dispatch_sync(queue, { () -> Void in
        
            if (self.data.count == 0 && self.itemCount < self.maxItemCount) {
                result = self.itemFactory()
                self.itemCount++
            } else {
                result = self.data.removeAtIndex(0);
            }
        })
        
        }
        return result
    }
...

Caution:DISPATCH_TIME_NOW 常量只能在dispatch_time方法中使用。如果你在其他地方使用，只會返回0。

我們將waitTime的值作為參數(shù)傳遞給了dispatch_semaphore_wait方法。

...
if (dispatch_semaphore_wait(semaphore, waitTime) == 0) {
...

dispatch_semaphore_wait 方法會一直阻塞直到returnToPool方法中的信號量發(fā)出信號或者超過指定的等待時間。

我們需要知道為什么信號量(semaphore)允許線程繼續(xù)執(zhí)行。如果是因為在對象池里有對象可用了，那么我們將獲取對象并交給請求組件。如果是因為超過等待時間， 那么我們希望返回一個空值。

getFromPool方法已經(jīng)是返回一個可選類型的Book對象。這就意味著Library 類已經(jīng)設(shè)置好了應(yīng)對獲取對象失敗的情況。

Library .swift

...
    func checkoutBook(reader:String) -> Book? {
        let book = pool.getFromPool()
        book?.reader = reader
        book?.checkoutCount++
        return book
    }
...

所以現(xiàn)在我們修改main.swift：

main.swift

import Foundation

var queue = dispatch_queue_create("workQ", DISPATCH_QUEUE_CONCURRENT)
var group = dispatch_group_create()
print("Starting...")
for i in 1 ... 35{
    dispatch_group_async(group, queue, {() in
        var book = Library.sharedInstance.checkoutBook("reader#\(i)")
        if (book != nil) {
            NSThread.sleepForTimeInterval(Double(rand() % 2))
            Library.sharedInstance.returnBook(book!)
        }else{
            dispatch_barrier_async(queue, { () -> Void in
                 print("Request \(i) failed")
            })
        }
    })
}

dispatch_group_wait(group, DISPATCH_TIME_FOREVER)

dispatch_barrier_sync(queue, {() -> Void in
        print("All blocks complete")
        Library.sharedInstance.printReport()
    })

如果沒有獲取到對象，我們就向控制臺輸出失敗信息。因為print方法并不是線程安全的，所謂我們把它放進(jìn)了GCD塊中。這里我們用了 dispatch_barrier_async是因為是并發(fā)隊列(DISPATCH_QUEUE_CONCURRENT)。
如果我們運行程序，會得到下面的輸出：


處理枯竭的對象池

前面所介紹的空對象池策略的問題是當(dāng)池中對象耗盡時它要求請求組件等待。但是我們看到所有的對象都已經(jīng)因為過度使用被丟棄了，而對象池也沒有能力創(chuàng)建新的對象。

Pool.swift

import Foundation

class Pool<T> {
    private var data = [T]()
    private let queue = dispatch_queue_create("arrayQ", DISPATCH_QUEUE_SERIAL)
    private let semaphore:dispatch_semaphore_t
    private var itemCount = 0
    private let maxItemCount:Int
    private let itemFactory: () -> T
    private var ejectedItems = 0
    private var poolExhausted = false
    
    init(maxItemCount:Int, factory:() -> T) {
        self.itemFactory = factory
        self.maxItemCount = maxItemCount
        semaphore = dispatch_semaphore_create(maxItemCount)
    }
    
    func getFromPool(maxWaitSeconds:Int = 5) -> T? {
       var result:T?
        
       let waitTime = (maxWaitSeconds == -1) ? DISPATCH_TIME_FOREVER : dispatch_time(DISPATCH_TIME_NOW, (Int64(maxWaitSeconds) * Int64(NSEC_PER_SEC)))
       if (!poolExhausted) {
         if (dispatch_semaphore_wait(semaphore, waitTime) == 0) {
             if (!poolExhausted) {
                dispatch_sync(queue){() -> Void in
        
                    if (self.data.count == 0 && self.itemCount < self.maxItemCount) {
                        result = self.itemFactory()
                        self.itemCount++
                    } else {
                        result = self.data.removeAtIndex(0);
                    }
                }
              }
            }
        }
        return result
    }

    
    func returnToPool(item:T) {
        dispatch_async(queue) { () -> Void in
           let pitem = item as? PoolItem
           if (pitem!.canReuse) {
              self.data.append(item)
              dispatch_semaphore_signal(self.semaphore)
           }else{
             self.ejectedItems++
             if (self.ejectedItems == self.maxItemCount) {
                self.poolExhausted = true
                self.flushQueue()
            }
           }
        }
        
    }
        
        private func flushQueue() {
            let dQueue = dispatch_queue_create("drainer", DISPATCH_QUEUE_CONCURRENT)
            var backlogCleared = false
            
            dispatch_async(dQueue) { () -> Void in
                dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER)
                backlogCleared = true
                
            }
            
            dispatch_async(dQueue) { () -> Void in
                while (!backlogCleared) {
                    dispatch_semaphore_signal(self.semaphore)
                }
                
            }
            
        }
        
        
    func processPoolItems(callback:[T] -> Void) {
        dispatch_barrier_sync(queue){ () in
            callback(self.data)
        }
     }
        
}

上面所做的修改提出了兩個問題：識別對象池耗盡和在此期間拒絕任何請求。為了識別對象池什么時候耗盡，我們在returnToPool中記錄被丟棄的對象數(shù)。而且當(dāng)所有的對象都被丟棄時，我們將實例變量 poolExhausted的值設(shè)置為true并且調(diào)用了flushQueue方法。

同時我們修改了getFromPool方法，所以在等待信號量發(fā)出之前都會檢查屬性poolExhausted是否為false，這意味著如果對象池耗盡的時候來值組件的請求都將會立即返回。

第二個問題是處理那些剛好在對象池耗盡之前的請求。這些請求線程會一直等待知道GCD發(fā)出信號。很不幸的是，GCD信號量(semaphore)并沒有提供一個可以喚醒所有等待線程的方法，所以這里我們通過flushQueue 方法間接的去實現(xiàn)。

這里我們創(chuàng)建了另一個隊列并為它添加了兩個執(zhí)行塊。第一個執(zhí)行塊等待信號量并且當(dāng)信號發(fā)送時設(shè)置局部變量backLogCleared 為ture。

...
 dispatch_async(dQueue) { () -> Void in
                dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER)
                backlogCleared = true
                
            }
...

GCD信號量允許線程通過是先進(jìn)先出原則(FIFO)，這就意味著只有當(dāng)所有在對象池剛好耗盡之前等待的線程允許通過后，這個執(zhí)行塊線程才會允許被通過。

第二個執(zhí)行塊重復(fù)的向信號量發(fā)信號直到backLogCleared的值改變。

...
  dispatch_async(dQueue) { () -> Void in
           while (!backlogCleared) {
                dispatch_semaphore_signal(self.semaphore)
              }
   }
...

這里增加執(zhí)行塊的隊列是并發(fā)的，并且信號量會發(fā)出通知直到所有積壓的線程通過后。我想阻止那些等到信號量的請求去執(zhí)行修改數(shù)組的代碼，所以在信號量發(fā)出后也對poolExhausted的值做了檢查。

...
 if (!poolExhausted) {
         if (dispatch_semaphore_wait(semaphore, waitTime) == 0) {
             if (!poolExhausted) {
...

我們將maxWaitSeconds參數(shù)的值改為-1來測試。只有當(dāng)對象池耗盡的時候請求才會被拒絕，而且結(jié)果也和上面等待5秒的例子相似，但是這種實現(xiàn)阻止了當(dāng)請求等待時間無上限并且對象池耗盡時請求線程被鎖住的問題。下面是執(zhí)行結(jié)果：


創(chuàng)建一個靈活的對象池

如果對象池有能力創(chuàng)建對象滿足需求，那么就沒有必要拒絕組件的請求。在軟件開發(fā)方面，靈活的對象池可以一般用在那種需要創(chuàng)建額外的對象來滿足增長的需求的情況。

在現(xiàn)實中，為了滿足最高需求通常圖書館會從最近的分館借書。這并不是理想的解決方案，但也意味著借書的人不用在長時間的等待了。請看下面例子：

BookSource.swift

import Foundation

class BookSeller {
    class func buyBook(author:String, title:String, stockNumber:Int) -> Book {
        return Book(author: author, title: title, stock: stockNumber)
    }
}

class LibraryNetwork {
    class func borrowBook(author:String, title:String, stockNumber:Int) -> Book {
        return Book(author: author, title: title, stock: stockNumber)
    }
    
    class func returnBook(book:Book) {
        // do nothing
    }
}

接著我們修改對象池類：

import Foundation

class Pool<T> {
    private var data = [T]()
    private let queue = dispatch_queue_create("arrayQ", DISPATCH_QUEUE_SERIAL)
    private let semaphore:dispatch_semaphore_t
    
    private let itemFactory: () -> T
    private let peakFactory: () -> T
    private let peakReaper:(T) -> Void
    
    private var createdCount:Int = 0
    private let normalCount:Int
    private let peakCount:Int
    private let returnCount:Int
    private let waitTime:Int
    
    init(itemCount:Int, peakCount:Int, returnCount: Int, waitTime:Int = 2,
        itemFactory:() -> T, peakFactory:() -> T, reaper:(T) -> Void) {
        self.normalCount = itemCount
        self.peakCount = peakCount
        self.waitTime    = waitTime
        self.returnCount = returnCount
        self.itemFactory = itemFactory
        self.peakFactory = peakFactory
        self.peakReaper  = reaper
        self.semaphore   = dispatch_semaphore_create(itemCount)
    }
    
    func getFromPool() -> T? {
        var result:T?
        
        let expiryTime = dispatch_time(DISPATCH_TIME_NOW,(Int64(waitTime) * Int64(NSEC_PER_SEC)))
        
        if(dispatch_semaphore_wait(semaphore, expiryTime) == 0 ){
            dispatch_sync(queue, { () -> Void in
                if(self.data.count == 0){
                    result=self.itemFactory()
                    self.createdCount++
                }else{
                    result = self.data.removeAtIndex(0)
                }
            })
        }else{
            dispatch_sync(queue, { () -> Void in
                result = self.peakFactory()
                self.createdCount++
            })
        }
     
        return result
    }

    
    func returnToPool(item:T) {
        dispatch_async(queue) { () -> Void in
           if (self.data.count>self.returnCount && self.createdCount>self.normalCount) {
              self.peakReaper(item)
              self.createdCount--
           }else{
             self.data.append(item)
             dispatch_semaphore_signal(self.semaphore)
            }
           }
        }
    
        
    func processPoolItems(callback:[T] -> Void) {
        dispatch_barrier_sync(queue){ () in
            callback(self.data)
        }
     }
        
}

最后我們修改Library類：

...
    private init(stockLevel:Int) {
        var stockId = 1
        pool = Pool<Book>(
            itemCount:stockLevel,
            peakCount: stockLevel * 2,
            returnCount: stockLevel / 2,
            itemFactory: {() in
            return BookSeller.buyBook("Dickens, Charles",
            title: "Hard Times", stockNumber: stockId++)},
            peakFactory: {() in
            return LibraryNetwork.borrowBook("Dickens, Charles",
            title: "Hard Times", stockNumber: stockId++)},
            reaper: LibraryNetwork.returnBook
        )
    }
...

運行程序，得到一下輸出：


理解分配策略

分配策略決定了如何選擇一個可用對象去滿足一個請求。到目前為止，我們所用的是先進(jìn)先出策略(FIFO),將數(shù)組像隊列一樣使用。這個策略的優(yōu)點是使用簡單，但同時也意味著對象會被不均衡的分配，某些請求成功次數(shù)會多余其他請求。

對于大多數(shù)應(yīng)用來說，先進(jìn)先出策略都會很合適，但是有些應(yīng)用也會要求一些不同的分配策略。下面我們將返回最少利用次數(shù)的對象。

Pool.swift

import Foundation

class Pool<T> {
    private var data = [T]()
    private let queue = dispatch_queue_create("arrayQ", DISPATCH_QUEUE_SERIAL)
    private let semaphore:dispatch_semaphore_t
    
    private let itemFactory: () -> T
    private let itemAllocator:[T] -> Int
    private let maxItemCount:Int
    private var createdCount:Int = 0
    
    init(itemCount:Int, itemFactory:() -> T, itemAllocator:([T] -> Int)) {
        self.maxItemCount = itemCount
        self.itemFactory = itemFactory
        self.itemAllocator = itemAllocator
        self.semaphore = dispatch_semaphore_create(itemCount)
    }
    
    func getFromPool(maxWaitSeconds:Int = -1) -> T? {
        var result:T?
        
        if (dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER) == 0){
            dispatch_sync(queue, { () -> Void in
                if (self.data.count == 0) {
                    result = self.itemFactory()
                    self.createdCount++
                }else{
                    result = self.data.removeAtIndex(self.itemAllocator(self.data))
                }
            })
        }
     
        return result
    }

    
    func returnToPool(item:T) {
        dispatch_async(queue) { () -> Void in
            self.data.append(item);
            dispatch_semaphore_signal(self.semaphore)
        }
        
    }
        
    
    func processPoolItems(callback:[T] -> Void) {
        dispatch_barrier_sync(queue){ () in
            callback(self.data)
        }
     }
        
}

這是一個延遲創(chuàng)建對象并且固定大小的對象池。我們定義了一個初始化參數(shù)itemAllocator，它是一個接受數(shù)組為參數(shù)的閉包，這個閉包返回數(shù)組中選定對象的位置。
接著我們修改Library類：

Library.swift

...
    private init(stockLevel:Int) {
        var stockId = 1
        pool = Pool<Book>(
        itemCount:stockLevel,
        itemFactory: {() in
            return BookSeller.buyBook("Dickens, Charles",
            title: "Hard Times", stockNumber: stockId++)},
            itemAllocator: {( books) in return 0 }
        )
    }
...

這時閉包返回的是0，也就是先進(jìn)先出策略，運行程序：

我們再做修改，實現(xiàn)最少使用策略：

Library.swift

...
    private init(stockLevel:Int) {
        var stockId = 1
        pool = Pool<Book>(
        itemCount:stockLevel,
        itemFactory: {() in
            return BookSeller.buyBook("Dickens, Charles",
            title: "Hard Times", stockNumber: stockId++)},
        itemAllocator: {(books) in
            var selected = 0
            for index in 1 ..< books.count {
                if (books[index].checkoutCount < books[selected].checkoutCount) {
                    selected = index
                }
            }
            return selected}
        )
    }
...

此時運行程序，可以看出結(jié)果比FIFO策略更佳均衡：


最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 發(fā)現(xiàn) 關(guān)注 消息 iOS 第三方庫、插件、知名博客總結(jié) 作者大灰狼的小綿羊哥哥關(guān)注 2017.06.26 09:4...
    肇東周閱讀 15,359評論 4贊 61
  • 次日清晨。 “子默哥哥，救救我，不要丟下我……” 睡夢中，蘇瞳身體蜷縮著，嘴里不停的喃喃自語，她的眉頭緊蹙，額頭上...
    安若阡陌閱讀 374評論 0贊 1
  • 我們在準(zhǔn)備發(fā)起咖啡店和健康管理項目，還沒有完全制定出完整的合理的項目發(fā)起方案。（一直再完善）核心發(fā)起人已經(jīng)選定四五...
    7f8515619d98閱讀 261評論 0贊 1
  • 各位書友，周五早安！今天我們繼續(xù)共讀《掌控》第八章：以弱勝強的掌控術(shù)，讓你搞定那些難纏的人，請閱讀p219-p24...
    熱點榜中榜閱讀 21,307評論 1贊 7
  • 逝長煙悲途，幾經(jīng)零落，漸次何來甘味，去自苦多，憂愁日，少年時，且縱胡駒良馬，好生驅(qū)馳。 畫舫又成空，憑欄對日，嘆曲...
    林下杉杉閱讀 264評論 1贊 5

友情鏈接更多精彩內(nèi)容