Link Details

If you write a server this way it allows an unbounded number of threads to be created in response to requests. With enough concurrent requests available memory or threads would be exhausted leading the JVM to throw an OutOfMemoryError.

I would use java.util.concurrent.Executors.newFixedThreadPool(int) to get back an ExecutorService to handle inbound requests as follows:

ExecutorService requestService = Executors.newFixedThreadPool(100);

while(! isStopped()){

    Socket clientSocket = null;

    try {

        clientSocket = this.serverSocket.accept();

    } catch (IOException e) {

        if(isStopped()) {

            System.out.println("Server Stopped.");

            return;

        }

        throw new RuntimeException(

            "Error accepting client connection", e);

    }



    requestService.submit(

        new WorkerRunnable(

            clientSocket, "Multithreaded Server")

    );

}

That's what I thought too. But read this:

http://paultyma.blogspot.com/2008/03/writing-java-multithreaded-servers.html

It seems creating new threads is cheap, and not as resource intensive as 2-3 years ago. Context switching is cheap too, and so is synchronization.

Anyways, I planned to cover the thread pooled server version too, plus a NIO based server version too. The version you were reading about was only as far I as I got by now.

If you look closely at my code, you will also notice that I created a WorkerRunnable, not a WorkerThread. That was exactly to make it easier to switch to the thread pooled version.

Very good point. I read through http://paultyma.blogspot.com/2008/03/writing-java-multithreaded-servers.html and it completely changed my understanding of this issue. Threads really are a lot more scalable than they once were in Java.

Thank you for the link! This now has my vote.