From 5d1a7f9437be31c82b4744a7ab3fb9212c65ffe2 Mon Sep 17 00:00:00 2001 From: Kou Shuang Date: Wed, 13 Nov 2019 18:11:19 +0800 Subject: [PATCH] =?UTF-8?q?=E7=BA=BF=E7=A8=8B=E6=B1=A0=E5=A4=A7=E5=B0=8F?= =?UTF-8?q?=E7=A1=AE=E5=AE=9A?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...244\247\345\260\217\347\241\256\345\256\232.md" | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 "docs/java/Multithread/\347\272\277\347\250\213\346\261\240\345\244\247\345\260\217\347\241\256\345\256\232.md" diff --git "a/docs/java/Multithread/\347\272\277\347\250\213\346\261\240\345\244\247\345\260\217\347\241\256\345\256\232.md" "b/docs/java/Multithread/\347\272\277\347\250\213\346\261\240\345\244\247\345\260\217\347\241\256\345\256\232.md" new file mode 100644 index 00000000..d014b143 --- /dev/null +++ "b/docs/java/Multithread/\347\272\277\347\250\213\346\261\240\345\244\247\345\260\217\347\241\256\345\256\232.md" @@ -0,0 +1,14 @@ +**线程池数量的确定一直是困扰着程序员的一个难题，大部分程序员在设定线程池大小的时候就是随心而定。我们并没有考虑过这样大小的配置是否会带来什么问题，我自己就是这大部分程序员中的一个代表。** + +由于笔主对如何确定线程池大小也没有什么实际经验，所以，这部分内容参考了网上很多文章/书籍。 + +首先，可以肯定的一点是线程池大小设置过大或者过小都会有问题。如果阅读过我的上一篇关于线程池的文章的话，你一定知道： + +> 如果我们设置的线程池数量太小的话，如果同一时间有大量任务/请求需要处理，可能会导致大量的请求/任务在任务队列中排队等待执行，甚至会出现任务队列满了之后任务/请求无法处理的情况，或者大量任务堆积在任务队列导致 OOM。这样很明显是有问题的！ CPU 根本没有得到充分利用。 +> +> 但是，如果我们设置线程数量太大，大量线程可能会同时在争取 CPU 资源，这样会导致大量的上下文切换，从而增加线程的执行时间，影响了整体执行效率。 + +有一个简单并且适用面比较广的公式： + +- **CPU 密集型任务(N+1)：**这种任务消耗的主要是 CPU 资源，可以将线程数设置为 N（CPU 核心数）+1，比 CPU 核心数多出来的一个线程是为了防止线程偶发的缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU 就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间。 +- **I/O 密集型任务(2N)：**这种任务应用起来，系统会用大部分的时间来处理 I/O 交互，而线程在处理 I/O 的时间段内不会占用 CPU 来处理，这时就可以将 CPU 交出给其它线程使用。因此在 I/O 密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是 2N。 \ No newline at end of file -- GitLab