|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-12-07
happysoul 写道 paulwong 写道 如果每天十万条线程这种级别的，是否建议使用ThreadExecutorPool？
能用10w个线程？你不会是用来群发垃圾邮件用的吧？ 即使是10w个 你也应该分段执行 按照几百一个阶段循环调用，或者定时监控队列然后填充待运行的线程而不是一次全都扔进去 最主要的是 tcp/ip 带宽 是一个很大的问题，即使你扔进去了10w，后期等待的时间还是固定的，尽量不要大量占用内存空间 再就是 非要单机运行这么多线程，这么考虑问题本身就有问题，多线程的原理就是cpu随机去执行多个任务，中途会多次挂起单个线程去运行其他线程。 每天都这么多 就应该考虑 远程调用分配执行任务的方式搭建你的服务了，一台任务分发服务器+多台供远程调用多线程的服务武器 分发端负责分配线程任务分配，然后将任务分发至多台执行并定时获取被调用端执行进度.................. 有做分布式的，十万分到每个JVM也就是一万左右。将这一万往队列里面塞也是可以的，同时运行的线程数就设为10，队列数取自然数的最大值，基本够用。 |
| 返回顶楼 | |
|
发表时间：2011-12-08
有点好奇，象EJB的SESSION BEAN处理高并发量的做法是不是也是这种机制。
|
| 返回顶楼 | |
|
发表时间：2011-12-08
paulwong 写道 如果每天十万条线程这种级别的，是否建议使用ThreadExecutorPool？
好像应该用吧 ~~ |
| 返回顶楼 | |
|
发表时间：2011-12-09
这是比较基础的知识，不懂的同学，请买本《java并发编程实践》好好看一下。
|
| 返回顶楼 | |
|
发表时间：2011-12-09
jameswxx 写道 这是比较基础的知识，不懂的同学，请买本《java并发编程实践》好好看一下。
中文版据说很翻译的很烂 |
| 返回顶楼 | |
|
发表时间：2011-12-10
我也用这个，不过还是建议得根据实际的情况进行设置。
核心线程数和最大线程数要根据实际调优得出来。 另外我一个体会是使用无界的LinkedBlockingQueue一定要小心，弄不好你的任务里面一旦由于某种原因导致处理速度慢的话，OOM就来了啊。 |
| 返回顶楼 | |
|
发表时间：2011-12-12
daly1987 写道 我也用这个，不过还是建议得根据实际的情况进行设置。
核心线程数和最大线程数要根据实际调优得出来。 另外我一个体会是使用无界的LinkedBlockingQueue一定要小心，弄不好你的任务里面一旦由于某种原因导致处理速度慢的话，OOM就来了啊。 如果是在SERVLET中启用线程，是取不了上下文。 |
| 返回顶楼 | |
|
发表时间：2012-08-08
所以建议： maximumPoolSize >= corePoolSize =期望的最大线程数。 (我曾经配置了corePoolSize=1, maximumPoolSize=20, blockqueue为无界队列，最后就成了单线程工作的pool。典型的配置错误)
官方给出的解释是 corePoolSize - the number of threads to keep in the pool, even if they are idle. maximumPoolSize - the maximum number of threads to allow in the pool.大致上还是说是线程池呀? 这里不是很明白.请楼主给解惑.
|
| 返回顶楼 | |
|
发表时间：2012-11-05
最后修改：2012-11-05
因为项目需要花了点时间做了个带缓存的有界队列实现，能很好的解决使用ThreadPoolExecutor的常见问题。目前该组件已经开源，地址https://github.com/netcomm/sponge。代码实现非常简单，类也很少。有任何问题都可以在github上提出或联系我。
sponge介绍 #使用方式跟普通的ThreadPoolExecutor没有任何差别，开发人员没有任何感觉。 #在突发情况极大并发请求下，保证系统的稳定性为第一目标。 #能自动缓冲超过某个阀值的任务请求。 #缓冲持久化的方式灵活，可根据使用场景进行选择，如基于文件(系统吞吐量巨大)、数据库(系统吞吐量大)、redis(系统吞吐量巨大)、…。 #任务的请求处理顺序默认先进先出模式。 #实现原理简单、代码精简。 #默认实现基于文件的缓冲持久化模式。 #关键参数可调整。 |
| 返回顶楼 | |
|
发表时间：2012-11-06
1. pool threads启动后，以后的任务获取都会通过block queue中，获取堆积的runnable task.
所以建议： block size >= corePoolSize ，不然线程池就没任何意义 这个不懂？不是说当提交的任务数超过了corePoolSize，才会将当前的runable提交到一个block queue中吗？ 为什么pool threads启动后，以后的任务获取都会通过block queue中了？ |
| 返回顶楼 | |
