快捷導(dǎo)航

IO密集型任務(wù)設(shè)置線程池線程數(shù)實現(xiàn)方式

更新時間：2024年07月04日 09:46:58 作者：瘋狂佩奇

這篇文章主要介紹了IO密集型任務(wù)設(shè)置線程池線程數(shù)實現(xiàn)方式,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教

任務(wù)類型

CPU密集

CPU密集型的話，一般配置CPU處理器個數(shù)+/-1個線程，所謂CPU密集型就是指系統(tǒng)大部分時間是在做程序正常的計算任務(wù)，例如數(shù)字運(yùn)算、賦值、分配內(nèi)存、內(nèi)存拷貝、循環(huán)、查找、排序等，這些處理都需要CPU來完成。

IO密集

IO密集型的話，是指系統(tǒng)大部分時間在跟I/O交互，而這個時間線程不會占用CPU來處理，即在這個時間范圍內(nèi)，可以由其他線程來使用CPU，因而可以多配置一些線程。（線程處于io等待或則阻塞狀態(tài)時,不會占用CPU資源）

混合型

混合型的話，是指兩者都占有一定的時間。

實際上工作中的大部分場景中，線程池的能力往往會超出想象。

測試準(zhǔn)備

下面的計算方式很粗略，而且有漏洞，但是也可以作為一個參考

處理器信息

四核8線程（超線程）

任務(wù)示例

我們首先確認(rèn)一下單個任務(wù)的io時間占比,下面是測試代碼

class ThreadPoolTest {
 
    public static int PARK_TIME = 0;
 
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        runTask(1);
    }
 
    public static void runTask(int threadNum) throws ExecutionException, InterruptedException {
        ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
            threadNum, threadNum, 1, TimeUnit.SECONDS, new LinkedBlockingDeque<>(100)
        );
 
        long start = System.currentTimeMillis();
        List<Future<?>> taskList = new ArrayList<>();
        for (int i = 0; i < 1; i++) {
            taskList.add(threadPoolExecutor.submit(() -> {
                doJob();
            }));
        }
        for (Future<?> future : taskList) {
            future.get();
        }
        long time = System.currentTimeMillis() - start;
        System.out.println(threadNum + "個線程，耗時：" + time + "停頓占比" + (PARK_TIME * 100.0 / time));
        threadPoolExecutor.shutdown();
    }
 
 
    public static Long doJob() {
        long result = 0L;
        PARK_TIME = 0;
        for (int i = 0; i < Integer.MAX_VALUE; i++) {
            if (i % 10_000_000 == 0) {
                try {
                    ++PARK_TIME;
                    // 模擬IO
                    LockSupport.parkNanos(100_000_000);
                } catch (Exception ignore) {
                }
            }
            result += i;
        }
        return result;
    }
}

執(zhí)行結(jié)果

直接運(yùn)行輸出如下：

1個線程，耗時：27862停頓占比0.7716603258918958

也就是說大概77%的時間線程在睡覺。

分析

按我電腦的配置可以認(rèn)為核心數(shù)coreNum為8，假設(shè)任務(wù)數(shù)夠多的情況下。

不考慮上下文切換等的耗時，單個任務(wù)io耗時占比為x,在線程數(shù)最少的情況下想讓cpu利用率達(dá)到最高，可以得出一個等式 1 / (1 - x) * coreNum = 100% * coreNum（我們假設(shè)線程在活躍狀態(tài)時能完全占用單個核心）。

代入上面得到的值 x = 0.77, coreNum = 8 可以比較容易的算出來如果想讓cpu利用率達(dá)到最高， 1 / (1 - 0.77) * 8 約等于34。即線程池的線程數(shù)設(shè)置為35比較合理。

在我的電腦上合適的線程數(shù)和任務(wù)io耗時占比x的關(guān)系大致可以認(rèn)為 1 / (1 - x) * 8，即理論上的圖如下,這是一個非常粗糙的等式，實際上隨著線程數(shù)增多，上下文切換帶來的開銷越來越大，和下面這張圖的出入還是蠻大的。

不同線程數(shù)下的程序總執(zhí)行耗時

下面簡單修改下程序來驗證一下任務(wù)量固定，不同線程數(shù)下的程序執(zhí)行耗時。

代碼

class ThreadPoolTest {
    
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        List<Integer> threadNumList = Arrays.asList(4, 8, 16, 25, 34, 50);
        for (Integer threadNum : threadNumList) {
            runTask(threadNum);
        }
    }
 
    public static void runTask(int threadNum) throws ExecutionException, InterruptedException {
        ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
            threadNum, threadNum, 1, TimeUnit.SECONDS, new LinkedBlockingDeque<>(100)
        );
 
        long start = System.currentTimeMillis();
        List<Future<?>> taskList = new ArrayList<>();
        for (int i = 0; i < 55; i++) {
            taskList.add(threadPoolExecutor.submit(() -> {
                doJob();
            }));
        }
        for (Future<?> future : taskList) {
            future.get();
        }
        long time = System.currentTimeMillis() - start;
        System.out.println(threadNum + "個線程，耗時：" + time);
        threadPoolExecutor.shutdown();
    }
 
 
    public static Long doJob() {
        long result = 0L;
        for (int i = 0; i < Integer.MAX_VALUE; i++) {
            if (i % 10_000_000 == 0) {
                try {
                    LockSupport.parkNanos(100_000_000);
                } catch (Exception ignore) {
                }
            }
            result += i;
        }
        return result;
    }
}

執(zhí)行結(jié)果

4個線程，耗時：3670028個線程，耗時：19075116個線程，耗時：10835825個線程，耗時：7863234個線程，耗時：5315140個線程，耗時：5356345個線程，耗時：5519650個線程，耗時：55729

期間cpu占用情況如下

總結(jié)

1.線程數(shù)從4-34期間耗時基本上穩(wěn)步縮減，但是線程數(shù)從34變成50的時候耗時并沒有明顯減少，反而有增加的趨勢，只有cpu利用率一直在飆升。io密集型任務(wù)線程池任務(wù)的確有一個較優(yōu)解的，超過這個邊界再繼續(xù)增加線程數(shù)，算力會被上下文切換給浪費掉，在執(zhí)行CPU密集型任務(wù)時這個現(xiàn)象會更加明顯。

2.即使是50個線程的時候，算力依然有剩余，并沒有達(dá)到100%利用率。這是因為，單個線程在活躍狀態(tài)下也并不能完全占用單個核心的所有時間片

3.每次任務(wù)執(zhí)行完都有一個小落差，這個可以自己思考一下為什么。

附

不同線程執(zhí)行耗時以及資源利用率

34個線程，耗時：60389
35個線程，耗時：54077
36個線程，耗時：54886
37個線程，耗時：55035
38個線程，耗時：55231
39個線程，耗時：53961
40個線程，耗時：53701
41個線程，耗時：54406
42個線程，耗時：54794
43個線程，耗時：53585
44個線程，耗時：52690
45個線程，耗時：55242