Page History

On the other hand, there can be several disadvantages of this design such as creation overhead in case of frequent or recurring requests, significant processing overhead, resource exhaustion pertaining to threads (leading to the {{OutOfMemoryError}}), thread scheduling and context switching overhead \[[Lea 00|AA. Java References#Lea 00]\].   

class Helper {
  public void handle(String request) {
    //... 		
  }	
}

class GetRequest {
  protected final Helper h = new Helper();
  String request;

  public synchronized String accept() {
    String data = "Read data from pipe";
    //read the request data, else block
    return data;
  }

  public void request() {
    while(true) {
      request = accept();
      new Thread(new Runnable() {
        public void run() {
          h.handle(request);
        }
      }).start();
    }
  }
}

This compliant solution uses a _Fixed Thread Pool_ that places an upper bound on the number of simultaneously executing threads. Tasks submitted to the pool are stored in an internal queue. The system will not get overwhelmed trying to respond to all incoming requests but will degrade gracefully by serving a fixed number of clients at a particular time. \[[Tutorials 08|AA. Java References#Tutorials 08]\]

According to \[[API 06|AA. Java References#API 06]\] the {{java.util.concurrent}} Interface {{Executor}}:

import java.util.concurrent.Executors;

class GetRequest {
  protected final Helper h = new Helper();
  String request;

  public synchronized String accept() {
    String data = "Read data from pipe";
    //read the request data, else block
    return data;
  }

  public void request() {
    int NoOfThreads = 200;
    Executor exec = (Executor) Executors.newFixedThreadPool(NoOfThreads);
    while(true) {
      request = accept();
      exec.Execute(new Runnable() {
        public void run() {
          h.handle(request);
        }
      });
    }
  }
}

This noncompliant code example shows a _thread starvation deadlock_. This situation not only occurs in singe threaded Executors, but also in those with large Thread Pools. This can happen when all the threads executing in the pool are blocked on tasks that are waiting on the queue. A blocking operation within a subtask can also lead to unbounded queue growth. \[[Goetz 06|AA. Java References#Goetz 06]\] 

class NetworkServer extends InitialHandshake implements Runnable {
  private final ServerSocket serverSocket;
  private final ExecutorService pool;

  public NetworkServer(int port, int poolSize) throws IOException {
    serverSocket = new ServerSocket(port);
    pool = Executors.newFixedThreadPool(poolSize);
  }
 
  public void run() {
    try { 
          //Interdependent tasks
   	  pool.submit(new SanitizeInput(password));  // password is defined in class InitialHandshake
   	  pool.submit(new CustomHandshake(password));  // for e.g. client puzzles 
          pool.execute(new Handle(serverSocket.accept()));  // handle connection
    } catch (IOException ex) { pool.shutdown(); }	 
  }
}

Sometimes, a {{private static}} {{ThreadLocal}} variable is used per thread to maintain local state. With Thread Pools, these should be employed only if their lifetime is shorter than the life of the corresponding task \[[Goetz 06|AA. Java References#Goetz 06]\]. Moreover, such variables should not be used as a communication mechanism between tasks. Finally, the choice of the unbounded  {{newFixedThreadPool}} may not always be the best. Refer to the API documentation for choosing between the former, {{newCachedThreadPool}}, {{newSingleThreadExecutor}} and {{newScheduledThreadPool}} to suit the design requirements.

class NetworkServer extends InitialHandshake implements Runnable {
  private final ServerSocket serverSocket;
  private final ExecutorService pool;

  public NetworkServer(int port, int poolSize) throws IOException {
    serverSocket = new ServerSocket(port);
    pool = Executors.newFixedThreadPool(poolSize);
  }
 
  public void run() {
    try {
      // Execute interdependent subtasks as a single combined task within this block
      pool.execute(new Handle(serverSocket.accept())); // handle connection
    } catch (IOException ex) { pool.shutdown(); }	 
  }
}

\[[API 06|AA. Java References#API 06]\] [Interface Executor|http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html]
\[[Lea 00|AA. Java References#Lea 00]\] Section 4.1.3 Thread-Per-Message and 4.1.4 Worker Threads
\[[Tutorials 08|AA. Java References#Tutorials 08]\] [Thread Pools|http://java.sun.com/docs/books/tutorial/essential/concurrency/pools.html]
\[[Goetz 06|AA. Java References#Goetz 06]\] Chapter 8, Applying Thread Pools
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 405|http://cwe.mitre.org/data/definitions/405.html] "Asymmetric Resource Consumption (Amplification)", [CWE ID 410|http://cwe.mitre.org/data/definitions/410.html] "Insufficient Resource Pool"