黑马程序员技术交流社区

标题: 关于线程池 ThreadPoolExecutor [打印本页]

---

作者: 马振兴    时间: 2012-11-7 17:41
标题: 关于线程池 ThreadPoolExecutor


线程池是JDK1.5的新特性。

哪位来说说他到底是一个什么样的概念呢？

相比传统的线程机制有哪些优势呢？

他的具体用法是怎么样的呢？

---

作者: 徐丹    时间: 2012-11-7 18:35
线程池ThreadPoolExecutor继承自ExecutorService。是jdk1.5加入的新特性，将提交执行的任务在内部线程池中的可用线程中执行。
我们可以把一个线程池（ThreadPoolExecutor）想成公司的一个部门
A（Executors.newCachedThreadPool）：这个部门负责处理从客户那里分配过来的任务（Task）。在部门刚刚建立之初人力资源部设定了部门人员的上限（maximumPoolSize=60）和下限（corePoolSize=0)，并要求部门经理等到第一个任务到来的时候才可以招收第一个组员（直到需要时才创建线程）。部门还制定了一个自己的工作制度，那就是我们绝不能够让任务积压！部门一成立，任务便从客户那边分配过来，部门经理为每一个任务招收一名员工。当员工完成手头的工作，部门经理为他们放假一段时间（keepAliveTime）进行休息。经过休整回来的员工，精神满满的等待接受经理给你派发的任务继续快乐的工作。可是这段时间经济不景气，没有那么多工作需要完成，处于节约成本的考虑，公司要把没有活干的非核心员工（由于corePoolSize=0，所以部门没有核心员工）解雇。到了年底，工作越来越多，部门经理继续招人，直到部门人数达到了上限，每一个员工都在拼命地工作没有一丝喘息的机会。这时又一个任务分配给了这个命苦的部门，也就是这个任务成为了击垮部门的最后一根稻草。部门经理受不了了，决定抗议：我们干不了更多的工作了（AbortPolicy）！
B（Executors.newFixedThreadPool）：这个部门负责处理从客户那里分配过来的任务（Task）。在部门刚刚建立之初人力资源部设定了部门人员的下限（corePoolSize)。并要求部门经理等到第一个任务到来的时候才可以招收第一个组员（直到需要时才创建线程）。部门还制定了一个自己的工作制度，那就是我们绝不能够让任务积压的太多（LinkedBlockingQueue.capacity）！部门一成立，任务便从客户那边分配过来，部门经理为每一个任务招收一名员工。一直等到部门人数达到部门人员的下限就不能再招人了。多余的任务就要搁置在任务积压列表中，等其他任务完成后再逐个完成。由于这个部门都是核心员工，所以大不用担心被解雇的问题了。当分配给部门的任务打过了积压任务的上限时，部门经理调出来说：我们干不了更多的工作了（AbortPolicy）！这个部门的工作人员下限可以设置，极端情况下部门只有一个员工（Executors.newSingleThreadExecutor）。
后来公司觉得，如果派发给部门的任务过多时，部门经理仅仅跳出来喊一声拒绝有点太过简单，还应该允许他做更多的事情化解危机。于是部门经理逐渐学会了ThreadPoolExecutor.CallerRunsPolicy（重试添加当前的任务，他会自动重复调用execute方法）。ThreadPoolExecutor.DiscardOldestPolicy（抛弃旧的任务）。 ThreadPoolExecutor.DiscardPolicy（抛弃当前的任务）。
由此可见，ThreadPoolExecutor线程池，兼顾了使用的方便性和扩展的灵活性。对于一般用途，借助Executors足以。若是将ThreadFactory ，RejectedExecutionHandler，BlockingQueue的不同实现灵活组合，又能满足各种情况下的需求真不枉为大家之作。

---

欢迎光临 黑马程序员技术交流社区 (http://bbs.itheima.com/)

黑马程序员IT技术论坛 X3.2