The thread pool of the contract and the structure of the second article--executors

The previous article described the implementation of threadpoolexecutor, and we can see a very obvious problem: the thread pool constructor is more complex, for programmers who do not quite understand how it works, it is possible for them to construct a different behavior than imagined. such as blocking the queue to put what, corepoolsize how to set up and so on.

So like the Math tool class, and the contract also provides a tool class: executors.

The first thing this tool class does is to provide static methods to help you construct different thread pools. So let's analyze its design pattern first:

1, static factory method mode, static method to help you construct the thread pool.

2, appearance mode, with a simple interface to shield the internal details. (That's a little farfetched)

The executors offers three main factories:

1      Public StaticExecutorservice Newfixedthreadpool (intnthreads) {2         return NewThreadpoolexecutor (Nthreads, Nthreads,30L, Timeunit.milliseconds,4                                       NewLinkedblockingqueue<runnable>());5     }6 7      Public StaticExecutorservice Newsinglethreadexecutor () {8         return NewFinalizabledelegatedexecutorservice9(NewThreadpoolexecutor (1, 1,Ten0L, Timeunit.milliseconds, One                                     NewLinkedblockingqueue<runnable>())); A     } -  -      Public StaticExecutorservice Newcachedthreadpool () { the         return NewThreadpoolexecutor (0, Integer.max_value, -30), Timeunit.seconds, -                                       NewSynchronousqueue<runnable>()); -}

The first: a fixed-size thread pool that must be constructed with the maximum number of threads (no matter how much more), while both Corepoolsize and Maximumpoolsize are set directly to this maximum number of threads parameter. The KeepAliveTime is set to 0. (There is no "journeywork", there is no journeywork of survival time)

Important: Why is the blocking queue an unbounded queue (in fact, not entirely unbounded: integer.maxvalue)? This is actually a very interesting place to design. We've talked about the running logic of the thread pool before. If the blocking queue is set to wireless, then after the actual number of threads reaches Corepoolsize, the thread will block in the queue. So as to ensure that: there is no "journeywork". It also limits the total size of the thread pool.

The second kind: the thread pool that only holds one threads, the corepoolsize and Maximumpoolsize are set to 1 directly, nothing to say

The third type: The thread pool is unbounded. While the blocking queue is a synchronousqueue, this queue is characterized by a blocking queue that does not hold objects. Each take must precede the put, in other words, the queue is not the same as the other first, which is the first "booking", waiting for a "arrival", immediately "delivery." Each operation is done first: then immediately block, and so on other people's corresponding operation to take, achieve almost direct delivery.

Logic becomes: Because the core pool size is 0, there is no permanent. Put in the line enters upgradeable try to enter the Synchronousqueue, if a worker has done their work before, go to synchronousqueue take the thread (and then be blocked), can achieve direct delivery to this idle worker execution. If there is a failure (no worker is idle), then a new worker is created directly into the maximumpool to start execution. And those who finished their task to go to synchronousqueue wait 60 seconds, if there is "order" to come, start work, whether the KeepAliveTime to be destroyed.

The thread pool of the contract and the structure of the second article--executors