一。 thread-per-connection
The thread-per-connection approach uses an exclusive worker thread for each connection. Within the handling loop, a worker thread
waits for new incoming data, processes the request, returns the response data, and calls the blocking socket's read method
public class Server {
private ExecutorService executors = Executors.newFixedThreadPool(10);
private boolean isRunning = true;
public static void main(String... args) throws ... {
new Server().launch(Integer.parseInt(args[0]));
}
public void launch(int port) throws ... {
ServerSocket sso = new ServerSocket(port);
while (isRunning) {
Socket s = sso.accept();
executors.execute(new Worker(s));
}
}
private class Worker implements Runnable {
private LineNumberReader in = null;
Worker(Socket s) throws ... {
in = new LineNumberReader(new InputStreamReader(...));
out = ...
}
public void run() {
while (isRunning) {
try {
// blocking read of a request (line)
String request = in.readLine();
// processing the request
String response = ...
// return the response
out.write(resonse);
out.flush();
} catch (Exception e ) {
...
}
}
in.close();
...
}
}
}
Because each connection has an associated thread waiting on the server side, very good response times can be achieved. However,
higher loads require a higher number of running, concurrent threads, which limits scalability. In particular, long-living connections
like persistent HTTP connections lead to a lot of concurrent worker threads, which tend to waste their time waiting concurrent
threads can waste a great deal of stack space. Note, for example, that the default Java thread stack size for Solaris is 512 KB.
二。thread-on-event
If a readiness event occurs, an event handler will be notified to perform the appropriate processing within dedicated worker threads.
To participate in the event architecture, the connection's Channel has to be registered on a Selector. This will be done by calling
the register method. Although this method is part of the SocketChannel, the channel will be registered on the Selector, not the
other way around.
SocketChannel channel = serverChannel.accept();
channel.configureBlocking(false); // register the connection
SelectionKey sk = channel.register(selector, SelectionKey.OP_READ);
To detect new events, the Selector provides the capability to ask the registered channels for their readiness events. By calling the select
method, the Selector collects the readiness events of the registered channels. This method call blocks until at least one event has been
occurred. In this case, the method returns the number of connections that have become ready for I/O operations since the last select call.
The selected connections can be retrieved by calling the Selector's selectedKey method. This method returns a set of SelectionKey objects,
which holds the IO event status and the reference of the connection's Channel.
A Selector is held by the Dispatcher. This is a single-threaded active class that surrounds the Selector. The Dispatcher is responsible to
retrieve the events and to dispatch the handling of the consumed events to the EventHandler.
Within the dispatch loop, the Dispatcher calls the Selector's select method to wait for new events. If at least one event has been occurred,
the method call returns and the associated channel for each event can be acquired by calling the selectedKeys method.
while (isRunning) {
// blocking call, to wait for new readiness events
int eventCount = selector.select();
// get the events
Iterator it = selector.selectedKeys().iterator();
while (it.hasNext()) {
SelectionKey key = it.next();
it.remove();
// readable event?
if (key.isValid() && key.isReadable()) {
eventHandler.onReadableEvent(key.channel());
}
// writable event?
if (key.isValid() && key.isWritable()) {
key.interestOps(SelectionKey.OP_READ); // reset to read only
eventHandler.onWriteableEvent(key.channel());
}
...
}
...
}
Because worker threads are not forced to waste time by waiting for new requests to open a connection, the scalability and
throughput of this approach is conceptually only limited by system resources like CPU or memory. That said, the response
times wouldn't be as good as for the thread-per-connection approach, because of the required thread switches and
synchronization. The challenge of the event-driven approach is therefore to minimize synchronizations and optimize thread
management, so that this overhead will be negligible.
三。构成
1.Acceptor
The Acceptor is a single threaded active class. Because it is only responsible for handling the very short-running
client connection request, it is often sufficient to implement the Acceptor using the blocking I/O model.
class Acceptor implements Runnable {
...
void init() {
ServerSocketChannel serverChannel = ServerSocketChannel.open();
serverChannel.configureBlocking(true);
serverChannel.socket().bind(new InetSocketAddress(serverPort));
}
public void run() {
while (isRunning) {
try {
SocketChannel channel = serverChannel.accept();
Connection con = new Connection(channel, appHandler);
dispatcherPool.nextDispatcher().register(con);
} catch (...) {
...
}
}
}
}
2.Dispatcher
Because the scalability of a single Dispatcher is limited, often a small pool of Dispatchers will be used. One reason for this limitation
is the operating-system-specific implementation of the Selector.
Most popular operating systems map a SocketChannel to a file handle in a one-to-one relationship. Depending on the concrete system,
the maximum number of file handles per Selector is limited in adifferent way.
The Selector manages the registered channels internally by using key sets. This means that by registering a channel, an associated
SelectionKey will be created and be added to the Selector's registered key set. At the same time, the concurrent dispatcher thread
could call the Selector's select method, which also accesses the key set.
Because the key sets are not thread-safe, an unsynchronized registration in the context of the Acceptor thread can lead to deadlocks
and race conditions. This can be solved by implementing the selector guard object idiom, which allows suspending the dispatcher
thread temporarily.
class Dispatcher implements Runnable {
private Object guard = new Object();
…
void register(Connection con) {
// retrieve the guard lock and wake up the dispatcher thread
// to register the connection's channel
synchronized (guard) {
selector.wakeup();
con.getChannel().register(selector, SelectionKey.OP_READ, con);
}
// notify the application EventHandler about the new connection
}
void announceWriteNeed(Connection con) {
SelectionKey key = con.getChannel().keyFor(selector);
synchronized (guard) {
selector.wakeup();
key.interestOps(SelectionKey.OP_READ | SelectionKey.OP_WRITE);
}
}
public void run() {
while (isRunning) {
synchronized (guard) {
// suspend the dispatcher thead if guard is locked
}
int eventCount = selector.select();
Iterator it = selector.selectedKeys().iterator();
while (it.hasNext()) {
SelectionKey key = it.next();
it.remove();
// read event?
if (key.isValid() && key.isReadable()) {
Connection con = (Connection) key.attachment();
disptacherEventHandler.onReadableEvent(con);
}
// write event?
}
}
}
}
4.Dispatcher-Level EventHandler
5.Application-Level EventHandler