java 线程池的处理

原来的网址:

http://abruzzi.iteye.com/blog/266335

网络请求通常有两种形式：第一种，请求不是很频繁，而且每次连接后会保持相当一段时间来读数据或者写数据，最后断开，如文件下载，网络流媒体等。另一种形式是请求频繁，但是连接上以后读/写很少量的数据就断开连接。考虑到服务的并发问题，如果每个请求来到以后服务都为它启动一个线程，那么这对服务的资源可能会造成很大的浪费，特别是第二种情况。因为通常情况下，创建线程是需要一定的耗时的，设这个时间为T1，而连接后读/写服务的时间为T2，当T1>>T2时，我们就应当考虑一种策略或者机制来控制，使得服务对于第二种请求方式也能在较低的功耗下完成。

通常，我们可以用线程池来解决这个问题，首先，在服务启动的时候，我们可以启动好几个线程，并用一个容器(如线程池)来管理这些线程。当请求到来时，可以从池中去一个线程出来，执行任务(通常是对请求的响应)，当任务结束后，再将这个线程放入池中备用；如果请求到来而池中没有空闲的线程，该请求需要排队等候。最后，当服务关闭时销毁该池即可。

• 结构

线程池中通常由这样几个概念(接口)组成：

1. 线程池(Thread pool )，池是一个容器，容器中有很多个执行器，每一个执行器是一个线程。当然，这个容器的实现，可以是链表，可以是数组等等，不需要关心，需要关心的是，池必须提供一个可以从中取出执行器的方法，可能还需要一个池中现有活动线程数方法，销毁池的方法等。
2. 执行器(Executor )，每个执行器是一个线程，每个执行器可以执行一个任务 ，任务是做什么，此时还不很明确，它需要提供任务的setter/getter方法，并且作为一个线程，他可以独立运行，执行器执行完自身后，需要将自身放入池中。
3. 任务(Task )，任务是每个线程具体要做的事，如资源下载，播放flash片段，打印一段文字到控制台等等，它本身不能执行，而需要将自身交给执行器。

整个池的机制和结构就是这样，当然，需要一个调度者(scheduler)来协调主线程和池的关系。结构，或者接口的目的是为了让我们从细节中解脱出来，从一个比较抽象的层次来描述系统，这样的好处是简单，而且设计出来的框架比较通用，可以适应很多相近相似的情况。由于Task具体干什么我们不知道，所以它几乎可以干任何适应于上边总结的网络连接的第二种情况(T1>>T2)。