對象池模式的變形

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

對象池模式的變形

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

理解對象池模式的變種

實現對象池包含四種策略：

對象的創建策略
對象的重用策略
空對象池策略
對象的分配策略

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

理解對象的創建策略

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

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)
    }
...

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

另一種策略就是延遲創建策略,就是只有當有需求時對象才被創建。這里我們創建一個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類定義了一個類方法用來創建Book對象。下面我們將修改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
           self.data.append(item)
           dispatch_semaphore_signal(self.semaphore)
        }
        
    }
    
    func processPoolItems(callback:[T] -> Void) {
        dispatch_barrier_sync(queue, {() in
            callback(self.data)
        })
    }
}

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

另一個改變是我們增加了一個方法processPoolItems用來記錄借出信息。因為在原來代碼中，對象的創建是由Library類中來實現，所以Library中可以保持對Book數組對引用。這里我們為了實現使用了回調方法來操作Book數組，而dispatch_barrier_sync保證了隊列中所有任務完成后才會執行回調方法。
最后我們修改Library 類實現延遲創建：

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")
                }
            }

        
        }
    }
}

如果執行程序，我們也許會得到以下的結果：

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的確切數字每次都會不同。最糟糕的情況是20本書全都被創建，那就意味著圖書館對于200本書的購買總額估計過高。如果我們這里使用饑餓策略，那么200本的副本都將被創建，延遲策略的優點就在于此。

理解對象的重用策略

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

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

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

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

我們將改變Book對象的使用方法來實現它們只能被借出特定的次數，反應了一個事實那就是書會承擔磨損和消耗直到沒辦法在使用。下面我們定義一個PoolItem的協議。

PoolItem.swift

import Foundation

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

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

Tip:注意到我們使用了@objc標注，這將支持對象向下轉型成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)
        })
    }
}

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

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

接著我們讓Book類實現PoolItem協議：

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
        }
    }
}

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

Library.swift

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

運行程序，得到下面結果：

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

理解空對象池策略

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

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

我們做如下修改：

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次，很顯然我們會得到下面的結果：

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

實現請求失敗策略

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

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的值作為參數傳遞給了dispatch_semaphore_wait方法。

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

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

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

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

Library .swift

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

所以現在我們修改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方法并不是線程安全的，所謂我們把它放進了GCD塊中。這里我們用了 dispatch_barrier_async是因為是并發隊列(DISPATCH_QUEUE_CONCURRENT)。
如果我們運行程序，會得到下面的輸出：

處理枯竭的對象池

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

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中記錄被丟棄的對象數。而且當所有的對象都被丟棄時，我們將實例變量 poolExhausted的值設置為true并且調用了flushQueue方法。

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

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

這里我們創建了另一個隊列并為它添加了兩個執行塊。第一個執行塊等待信號量并且當信號發送時設置局部變量backLogCleared 為ture。

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

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

第二個執行塊重復的向信號量發信號直到backLogCleared的值改變。

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

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

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

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

創建一個靈活的對象池

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

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

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
        )
    }
...

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

理解分配策略

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

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

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)
        }
     }
        
}

這是一個延遲創建對象并且固定大小的對象池。我們定義了一個初始化參數itemAllocator，它是一個接受數組為參數的閉包，這個閉包返回數組中選定對象的位置。
接著我們修改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，也就是先進先出策略，運行程序：

我們再做修改，實現最少使用策略：

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}
        )
    }
...

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

最后編輯于：2017.12.03 02:35:01

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發布，文章內容僅代表作者本人觀點，簡書系信息發布平臺，僅提供信息存儲服務。

人面猴
序言：七十年代末，一起剝皮案震驚了整個濱河市，隨后出現的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
沈念sama閱讀 229,885評論 6贊 541
死咒
序言：濱河連續發生了三起死亡事件，死亡現場離奇詭異，居然都是意外死亡，警方通過查閱死者的電腦和手機，發現死者居然都...
沈念sama閱讀 99,312評論 3贊 429
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人，你說我怎么就攤上這事。” “怎么了？”我有些...
開封第一講書人閱讀 177,993評論 0贊 383
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵，是天一觀的道長。經常有香客問我，道長，這世上最難降的妖魔是什么？我笑而不...
開封第一講書人閱讀 63,667評論 1贊 317
?港島之戀（遺憾婚禮）
正文為了忘掉前任，我火速辦了婚禮，結果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當我...
茶點故事閱讀 72,410評論 6贊 411
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布。她就那樣靜靜地躺著，像睡著了一般。火紅的嫁衣襯著肌膚如雪。梳的紋絲不亂的頭發上，一...
開封第一講書人閱讀 55,778評論 1贊 328
城市分裂傳說
那天，我揣著相機與錄音，去河邊找鬼。笑死，一個胖子當著我的面吹牛，可吹牛的內容都是我干的。我是一名探鬼主播，決...
沈念sama閱讀 43,775評論 3贊 446
雙鴛鴦連環套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側響起，我...
開封第一講書人閱讀 42,955評論 0贊 289
萬榮殺人案實錄
序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后，有當地人在樹林里發現了一具尸體，經...
沈念sama閱讀 49,521評論 1贊 335
?護林員之死
正文獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內容為張勛視角年9月15日...
茶點故事閱讀 41,266評論 3贊 358
?白月光啟示錄
正文我和宋清朗相戀三年，在試婚紗的時候發現自己被綠了。大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
茶點故事閱讀 43,468評論 1贊 374
活死人
序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
沈念sama閱讀 38,998評論 5贊 363
?日本核電站爆炸內幕
正文年R本政府宣布，位于F島的核電站，受9級特大地震影響，放射性物質發生泄漏。R本人自食惡果不足惜，卻給世界環境...
茶點故事閱讀 44,696評論 3贊 348
男人毒藥：我在死后第九天來索命
文/蒙蒙一、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
開封第一講書人閱讀 35,095評論 0贊 28
一樁弒父案，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽。三九已至，卻和暖如春，著一層夾襖步出監牢的瞬間，已是汗流浹背。一陣腳步聲響...
開封第一講書人閱讀 36,385評論 1贊 294
情欲美人皮
我被黑心中介騙來泰國打工，沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。一個月前我還...
沈念sama閱讀 52,193評論 3贊 398
代替公主和親
正文我出身青樓，卻偏偏與公主長得像，于是被迫代替她去往敵國和親。傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當晚...
茶點故事閱讀 48,431評論 2贊 378

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

對象池模式的變形

對象池模式的變形

對象池模式的變形

理解對象池模式的變種

理解對象的創建策略

理解對象的重用策略

理解空對象池策略

實現請求失敗策略

處理枯竭的對象池

創建一個靈活的對象池

理解分配策略

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

對象池模式的變形

對象池模式的變形

理解對象池模式的變種

理解對象的創建策略

理解對象的重用策略

理解空對象池策略

實現請求失敗策略

處理枯竭的對象池

創建一個靈活的對象池

理解分配策略

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频