通用池化框架GenericKeyedObjectPool性能測試

上次我測試了通用池化框架GenericObjectPool性能測試，效果還行，對後面使用commons-pool2框架的使用提供了非常有效的參考依據。

對於另外一個更復雜的GenericKeyedObjectPool也得安排上了，這就獻上。

硬件軟件配置&準備工作&可池化對象

這部分內容與上期相同，這裏不再贅述了。

池化工廠

這裏用到了org.apache.commons.pool2.BaseKeyedPooledObjectFactory<Integer, FunTesterPooled>，下面分享一下具體的代碼。

    /**
     * 池化工廠
     */
    private static class FunFactory extends BaseKeyedPooledObjectFactory<Integer, FunTesterPooled> {


        @Override
        FunTesterPooled create(Integer key) throws Exception {
            def pooled = new FunTesterPooled()
            pooled.setAge(key)
            return pooled
        }

        @Override
        PooledObject<FunTesterPooled> wrap(FunTesterPooled value) {
            return new DefaultPooledObject<FunTesterPooled>(value)
        }

        @Override
        void destroyObject(Integer key, PooledObject<FunTesterPooled> p, DestroyMode destroyMode) throws Exception {
            p.getObject().setAge(0)//資源回收
            super.destroyObject(key, p, destroyMode)
        }
    }

對象池

雖然這個GenericKeyedObjectPool理論上是可以存儲不同的對象的，但是這個在創建的時候還是需要確定一個可池化對象類型。所以後面所有創建的對象必需這個可池化對象類或者子類。

    /**
     * 初始化對象池
     * @return
     */
    static def initPool() {
        def config = new GenericKeyedObjectPoolConfig<FunTesterPooled>()
        config.setMaxTotal(thread * 2)
        config.setMinIdlePerKey(10)
        config.setMaxIdlePerKey(100)
        config.setMaxWait(Duration.ofMillis(1000))
        config.setMaxIdlePerKey(thread)
        config.setMaxIdlePerKey(10)
        config.setMinIdlePerKey(2)
        return new GenericKeyedObjectPool<Integer, FunTesterPooled>(new FunFactory(), config)
    }

這裏的設置分成了兩類，就是每個對象池和總對象池的各類參數設置。

性能測試用例

跟上期的用例很像，只是請求參數增加了key，這裏return的時候也需要增加key參數。測試用例如下：

    static GenericKeyedObjectPool<Integer, FunTesterPooled> pool

    static def desc = "池化框架性能測試"

    static int times = 200

    static int thread = 3

    public static void main(String[] args) {
        this.pool = initPool()
        ThreadBase.COUNT = true
        RUNUP_TIME = 0
        POOL_SIZE = thread
        thread.times {
            pool.addObjects(it, thread)
        }
        output("對象創建完畢 創建數量${pool.getNumIdle()}")
        new Concurrent(new FunTester(), thread, desc).start()
        pool.close()
    }

    private static class FunTester extends FixedThread {


        FunTester() {
            super(null, times, true)
        }

        @Override
        protected void doing() throws Exception {
            def randomInt = getRandomInt(thread)
            def object = pool.borrowObject(randomInt)
            pool.returnObject(randomInt, object)
        }

        @Override
        FunTester clone() {
            return new FunTester()
        }
    }

測試結果

用例設計也是跟上期的文章一樣，爲了儘可能有對比價值，使用了儘可能相同的參數。

無等待

線程數	執行次數（萬）	QPS
1	300	189501
2	300	322603
5	300	120334
10	100	96861
20	50	81440

可以看出，一旦線程數增加，QPS就是降低非常快，線程較低的時候性能跟GenericObjectPool相差無幾，這很可能是java.util.concurrent.ConcurrentHashMap導致的。有時間我再對java.util.concurrent.ConcurrentHashMap進行性能測試。

等待

使用了休眠2ms的配置。

線程數	執行次數(k)	單線程QPS
20	10	416
50	10	393
100	5	222
200	2	79
300	2	27

後面就不測了，再測可能迴歸個位數了。結論如上，線程數增加的的話，粗略估計100以上，org.apache.commons.pool2.impl.GenericKeyedObjectPoolConfig的性能就會變得奇差無比，可能是多種原因導致的。更不用提線程數增加500以後，會遇到org.apache.commons.pool2.impl.LinkedBlockingDeque和java.util.concurrent.atomic.AtomicLong性能大幅下降。看來以後還是不能簡單使用對象池代替創建對象。

Have Fun ~ Tester ！

• FunTester原創大賞
• 性能測試專題
• Java、Groovy、Go、Python
• FunTester社羣風采
• 測試理論雞湯
• 接口功能測試專題
• FunTester視頻專題
• 案例分享：方案、BUG、爬蟲
• UI自動化專題
• 測試工具專題

閱讀原文，跳轉我的倉庫地址