有什么区别 -
newSingleThreadExecutor vs newFixedThreadPool(20)
在操作系统和编程方面的观点。
每当我使用newSingleThreadExecutor
运行程序时,我的程序运行良好,端到端延迟(第95百分位数)来自5ms
。
但是一旦我开始使用 -
运行我的程序 newFixedThreadPool(20)
我的程序性能下降,我开始将端到端延迟视为37ms
。
所以现在我试图从架构的角度来理解这里有多少线程意味着什么?以及如何确定我应该选择的最佳线程数?
如果我使用更多线程,那会发生什么?
如果有人能用外行语言向我解释这些简单的事情那么这对我来说非常有用。谢谢你的帮助。
我的机器配置规范 - 我正在从Linux机器运行我的程序 -
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
stepping : 7
cpu MHz : 2599.999
cache size : 20480 KB
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm arat pln pts
bogomips : 5199.99
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
stepping : 7
cpu MHz : 2599.999
cache size : 20480 KB
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm arat pln pts
bogomips : 5199.99
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
答案 0 :(得分:39)
确定。理想情况下,假设您的线程没有锁定,使得它们不会相互阻塞(彼此独立),并且您可以假设工作负载(处理)相同,那么事实证明,池大小为{{1 }或Runtime.getRuntime().availableProcessors()
可以获得最佳效果。
但是,如果线程相互干扰或者I / O已经包含在内,那么Amadhal定律很好地解释了。来自维基,
Amdahl定律指出,如果P是可以并行的程序的比例(即,从并行化中受益),并且(1-P)是无法并行化的比例(保持连续),那么最大加速可以通过使用N个处理器来实现
在您的情况下,根据可用内核的数量,以及它们精确做的工作(纯计算?I / O?保持锁定?某些资源被阻止等等),您需要提出解决方案基于以上参数。
例如:几个月前,我参与了从数字网站收集数据。我的机器是4核的,我的游泳池大小为availableProcessors() + 1
。但是因为操作纯粹是4
并且我的网速很不错,所以我意识到我的游戏大小为I/O
时性能最佳。这是因为,线程不是为了计算能力,而是为了I / O。所以我可以利用更多线程可以积极争夺核心的事实。
PS:我建议,阅读Brian Goetz撰写的“Java并发实践”一书中的性能一章。它详细讨论了这些问题。
答案 1 :(得分:5)
所以现在我试图从架构的角度来理解这里有多少线程意味着什么?
每个线程都有自己的堆栈存储器,程序计数器(如指向下一个指令执行的指针)和其他本地资源。交换它们会损害单个任务的延迟。好处是当一个线程空闲时(通常在等待i / o时),另一个线程可以完成工作。此外,如果有多个处理器可用,如果任务之间没有资源和/或锁定争用,它们可以并行运行。
如何确定我应该选择的最佳线程数?
掉期价格与避免闲置时间的机会之间的权衡取决于你的任务看起来的细节(多少i / o,以及何时,i / o之间的工作量,使用方式如何很多记忆要完成)。实验始终是关键。
如果我使用更多线程,那会发生什么?
首先通常会有吞吐量的线性增长,然后是相对平坦的部分,然后是下降(可能非常陡峭)。每个系统都不同。
答案 2 :(得分:3)
看阿姆达尔定律很好,特别是如果你确切地知道P和N有多大。由于这种情况永远不会发生,您可以监控性能(无论如何应该执行)并增加/减少线程池大小以优化对您来说重要的性能指标。