Java Reference
In-Depth Information
We demonstrate the use of this dispatcher and protocol factory in ThreadMain.java , which
we introduce after discussing the thread-pool approach to dispatching.
4.1.5 Thread Pool
Every new thread consumes system resources: spawning a thread takes CPU cycles and each
thread has its own data structures (e.g., stacks) that consume system memory. In addition,
the scheduling and context switching among threads creates extra work. As the number
of threads increases, more and more system resources are consumed by thread overhead.
Eventually, the system is spending more time dealing with thread management than with
servicing connections. At that point, adding an additional thread may actually increase client
service time.
We can avoid this problem by limiting the total number of threads and reusing threads.
Instead of spawning a new thread for each connection, the server creates a thread pool on start-
up by spawning a fixed number of threads. When a new client connection arrives at the server,
it is assigned to a thread from the pool. When the thread finishes with the client, it returns to
the pool, ready to handle another request. Connection requests that arrive when all threads in
the pool are busy are queued to be serviced by the next available thread.
Like the thread-per-client server, a thread-pool server begins by creating a ServerSocket .
Then it spawns
threads, each of which loops forever, accepting connections from the
(shared) ServerSocket instance. When multiple threads simultaneously call accept() on the
same ServerSocket instance, they all block until a connection is established. Then the system
selects one thread, and the Socket instance for the new connection is returned only in that
thread . The other threads remain blocked until the next connection is established and another
lucky winner is chosen.
Since each thread in the pool loops forever, processing connections one by one, a thread-
pool server is really a set of iterative servers. Unlike the thread-per-client server, a thread-pool
thread does not terminate when it finishes with a client. Instead, it starts over again, blocking
on accept() .
A thread pool is simply a different model for dispatching connection requests, so all we
really need to do is write another dispatcher. PoolDispatcher.java implements our thread-pool
dispatcher. To see how the thread-pool server would be implemented without dispatchers and
protocol factories, see TCPEchoServerPool.java on the topic's Web site.
N
PoolDispatcher.java
0 import java.net.*; // for Socket and ServerSocket
1 import java.io.*;
// for IOException
2
3 class PoolDispatcher implements Dispatcher {
4
5
static final String NUMTHREADS = "8";
// Default thread−pool size
6
static final String THREADPROP = "Threads"; // Name of thread property
7
8
private int numThreads;
// Number of threads in pool
 
Search WWH ::




Custom Search