Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

Bounded thread pools allow the programmer to specify an upper limit on the number of threads that can concurrently execute in a thread pool. Programs must not use threads from a bounded thread pool to execute tasks that depend on the completion of other tasks in the pool.

A form of deadlock called thread-starvation deadlock arises when all the threads executing in the pool are blocked on tasks that are waiting on an internal queue for an available thread in which to execute. Thread-starvation deadlock occurs when currently executing tasks submit other tasks to a thread pool and wait for them to complete and the thread pool lacks the capacity to accommodate all the tasks at once.

This problem can be confusing because the program can function correctly when fewer threads are needed. The issue can be mitigated, in some cases, by choosing a larger pool size. However, determining a suitable size may be difficult or even impossible.

Similarly, threads in a thread pool may fail to be recycled when two executing tasks each require the other to complete before they can terminate. A blocking operation within a subtask can also lead to unbounded queue growth [Goetz 2006].

Noncompliant Code Example (Interdependent Subtasks)

This noncompliant code example is vulnerable to thread-starvation deadlock. It consists of the ValidationService class, which performs various input validation tasks such as checking whether a user-supplied field exists in a back-end database.

The fieldAggregator() method accepts a variable number of String arguments and creates a task corresponding to each argument to enable concurrent processing. The task performs input validation using the ValidateInput class.

In turn, the ValidateInput class attempts to sanitize the input by creating a subtask for each request using the SanitizeInput class. All tasks are executed in the same thread pool. The fieldAggregator() method blocks until all the tasks have finished executing and, when all results are available, returns the aggregated results as a StringBuilder object to the caller.

Code Block
bgColor#FFCCCC
public final 
Wiki Markup
Tasks that depend on other tasks should not be executed in the same thread pool. A task that submits another task to a single threaded {{Executor}} remains blocked until the results are received whereas the second task may have dependencies on the first task. This constitutes a deadlock. Another form of deadlock called thread starvation deadlock can arise when a task spawns several other tasks and waits for them to complete. Because of the limited thread pool size, only a fixed number of tasks can execute to completion at a particular time. In this case, neither task can finish executing when there are no available slots on the thread pool's work queue to accommodate the sub-tasks.

h2. Noncompliant Code Example

This noncompliant code example suffers from a _thread starvation deadlock_ issue. It consists of class {{ValidationService}} that performs various input validation tasks such as checking whether a user-supplied field exists in a back-end database. The {{fieldAggregator()}} method accepts a variable number of {{String}} arguments and creates a task corresponding to each argument to gain some speedup. The task performs input validation using class {{ValidateInput}}. The class {{ValidateInput}} in turn, attempts to sanitize the input by creating a task for each request using class {{SanitizeInput}}. All tasks are executed using the same thread pool. The method {{fieldAggregator()}} blocks until all the tasks have finished executing. When all results are available, it aggregates the processed inputs as a {{StringBuffer}} that is returned to its caller.

{code:bgColor=#FFCCCC}
class ValidationService {
  private final ExecutorService pool;

  public ValidationService(int poolSize) {
    pool = Executors.newFixedThreadPool(poolSize);
  }
  
  public void shutdown() {
    pool.shutdown();
  }
   
  public StringBufferStringBuilder fieldAggregator(String... inputs)
 
     throws InterruptedException, ExecutionException   {
   
    StringBufferStringBuilder sb = new StringBufferStringBuilder();
    Future<String>[] // Stores the results
    Future<String>[] results = new Future[inputs.length]; 

    // StoresSubmits the results
		
 tasks to thread pool
    for (int i = 0; i < inputs.length; i++) { // Submits the tasks to thread pool
      results[i] = pool.submit(
        new ValidateInput<String>(inputs[i], pool));     
    } 

    for (int i = 0; i < inputs.length; i++) { // Aggregates the results	    	
      sb.append(results[i].get());	    	
    }
    return sb;
  }
}

public final class ValidateInput<V> implements Callable<V> {
  private final StringV input;
  private final ExecutorService pool;

  ValidateInput(StringV input, ExecutorService pool) {
    this.input = input;
    this.pool = pool;
  }

  @Override public V call() throws Exception {
    // If validation fails, throw an exception here
    // Subtask
    Future<String>Future<V> future = pool.submit(new SanitizeInput<String>SanitizeInput<V>(input)); 
    return (V) future.get();
  }
}

public final class SanitizeInput<V> implements Callable<V> {
  private final StringV input;
	
  SanitizeInput(StringV input) {
    this.input = input;
  }

  @Override public V call() throws Exception {
    // Sanitize input and return
    return (V) input;	
  }
}
{code}

{mc}
// Hidden main() method
public static void main(String[] args) throws InterruptedException, ExecutionException {
  ValidationService vs = new ValidationService(5);
  System.out.println(vs.fieldAggregator("field1", "field2","field3","field4", "field5","field6"));
  vs.shutdown(); 
}
{mc}

Assume that the caller sets the thread pool size as 6. When it calls {{ValidationService.fieldAggregator()}} with six arguments that ought to be validated, six tasks are submitted to the thread pool. However, six more tasks corresponding to {{SanitizeInput}} must also execute before these threads can return their results. However, this is not possible because the queue is full with all threads blocked.  This issue is deceptive because the program may appear to function correctly when fewer arguments are supplied. Choosing a bigger pool size appears to solve the problem, however there is no easy way to determine a suitable size.   

This situation can also occur when using single threaded Executors when the caller creates several sub-tasks and waits for the results. A thread starvation deadlock arises 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]\] 


h2. Compliant Solution

This compliant solution refactors all three classes so that the tasks corresponding to {{SanitizeInput}} are not executed in a thread pool. Consequently, the tasks are independent of each other. An alternative is to use a different thread pool at each level, though in this example, another thread pool is not required.

{code:bgColor=#ccccff}
class ValidationService {
 // ...
 public StringBuffer fieldAggregator(String... inputs) 
   throws InterruptedException, ExecutionException {
   // ...
   for (int i = 0; i < inputs.length; i++) {
     results[i] = pool.submit(new ValidateInput<String>(inputs[i])); // Don't pass-in thread pool    
   } 
   // ...
 } 
}

public class ValidateInput<V> implements Callable<V> { // Does not use same thread pool
  private final String input;
	
  ValidateInput(String input) {
    this.input = input;
  }

  @Override public V call() throws Exception {
    // If validation fails, throw an exception here
    return (V)SanitizeInput.sanitizeString(input);
  }
}

public class SanitizeInput {  // No longer a Callable task	
  private SanitizeInput() { }

  public static String sanitizeString(String input) {
    // Sanitize input and return
    return input;	
  }
}
{code}

Always submit independent tasks to the {{Executor}}. Thread starvation issues can be mitigated by choosing a large pool size, however, the limitations of the application when using this approach should be clearly documented. 

Note that operations that have further constraints, such as the total number of database connections or total {{ResultSets}} open at a particular time, impose an upper bound on the thread pool size as each thread continues to block until the resource becomes available. The other rules of fair concurrency, such as not running time consuming tasks, also apply. When this is not possible, expecting to obtain real time result guarantees from the execution of tasks is conceivably, an unreasonable target.

Sometimes, a {{private static}} {{ThreadLocal}} variable is used per thread to maintain local state. When using thread pools, {{ThreadLocal}} variable should be used only if their lifetime is shorter than that of the corresponding task \[[Goetz 06|AA. Java References#Goetz 06]\]. Moreover, such variables should not be used as a communication mechanism between tasks. 

h2. Noncompliant Code Example

This noncompliant code example (based on \[[Gafter 06|AA. Java References#Gafter 06]\]) shows a {{BrowserManager}} class that has several methods that use a fork-join mechanism, that is, they start threads and wait for them to finish. The methods are called in the sequence {{perUser()}}, {{perProfile}} and {{perTab()}}. The method {{methodInvoker()}} spawns several instances of the specified runnable depending on the value of the variable {{numberOfTimes}}. A fixed sized thread pool is used to execute the enumerations of tasks created at different levels. 

{code:bgColor=#FFCCCC}
public class BrowserManager {
  private final ExecutorService pool = Executors.newFixedThreadPool(10);
  int numberOfTimes;
  private static volatile int count = 0;
  
  public BrowserManager(int n) {
    this.numberOfTimes = n;
  }

  public void perUser() {	
    methodInvoker(numberOfTimes, "perProfile"); 
    pool.shutdown();
  }

  public void perProfile() {
    methodInvoker(numberOfTimes, "perTab");	 
  }

  public void perTab() {	
    methodInvoker(numberOfTimes, "doSomething");
  }

  public void doSomething() {
    System.out.println(++count);
  }

  public void methodInvoker(int n, final String method) {
    final BrowserManager fm = this;
    Runnable run = new Runnable() {
      public void run() {
        try {
          Method meth = fm.getClass().getMethod(method);
          meth.invoke(fm);			
        } catch (Throwable t) {
	  // Forward to exception reporter
        }		  
      }
    };	
   
    Collection<Callable<Object>> c = new ArrayList<Callable<Object>>();
    for(int i=0;i < n; i++) {
      c.add(Executors.callable(run));
    }
	
    Collection<Future<Object>> futures = null;
    try {
      futures = pool.invokeAll(c);
    } catch (InterruptedException e) {     
      // Forward to handler	
    }
    // ... 
  }

  public static void main(String[] args) {
    BrowserManager manager = new BrowserManager(5);
    manager.perUser();
  }	
}
{code}

Contrary to what is expected, this program does not print the total count, that is, the number of times {{doSomething()}} is invoked. This is because it is susceptible to a thread starvation deadlock because the size of the thread pool (10) does not allow either thread from {{perTab()}} to invoke the {{doSomething()}} method. The output of the program varies for different values of {{numberOfTimes}} and the thread pool size. Note that different threads are allowed to invoke {{doSomething()}} in different orders; we are concerned only with the maximum value of {{count}} to determine how many times the method executed.

h2. Compliant Solution

This compliant solution selects tasks for scheduling and avoids the thread starvation deadlock. Every level (worker) must have a double ended queue where all sub-tasks are queued. Each level removes the most recently generated sub-task from the queue so that it can process it. When there are no more threads left to process, the current level runs the least-recently created sub-task of another level by picking and removing it from that level's queue. 

This compliant solution sets the {{CallerRuns}} policy on a {{ThreadPoolExecutor}}, and uses a synchronous queue \[[Gafter 06|AA. Java References#Gafter 06]\].

{code:bgColor=#ccccff}
public class BrowserManager {
  static ThreadPoolExecutor pool =
    new ThreadPoolExecutor(0, 10, 60L, TimeUnit.SECONDS,
                          new SynchronousQueue<Runnable>());
  int numberOfTimes;
  private static volatile int count = 0;

  static {
    pool.setRejectedExecutionHandler(
    new ThreadPoolExecutor.CallerRunsPolicy());
  }

  // ... 
}	
{code}

According to the Java API, class {{java.util.concurrent.ThreadPoolExecutor.CallerRunsPolicy}} documentation:

{quote}
A handler for rejected tasks that runs the rejected task directly in the calling thread of the {{execute}} method, unless the executor has been shut down, in which case the task is discarded. 
{quote}

This compliant solution is subject to the vagaries of the thread scheduler which may not optimally schedule the tasks, however, it avoids the thread starvation deadlock.

h2. Risk Assessment

Executing interdependent tasks in a thread pool can lead to denial of service.

|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level ||
| CON29- J | low | probable | medium | {color:green}{*}P4{*}{color} | {color:green}{*}L3{*}{color} |

h3. Automated Detection

TODO

h3. Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the [CERT website|https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+FIO38-J].

h2. References

\[[API 06|AA. Java References#API 06]\] 
\[[Gafter 06|AA. Java References#Gafter 06]\] [A Thread Pool Puzzler|http://gafter.blogspot.com/2006/11/thread-pool-puzzler.html]

----
[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!|FIO36-J. Do not create multiple buffered wrappers on an InputStream]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_up.png!|09. Input Output (FIO)]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_right.png!|09. Input Output (FIO)]

Assume, for example, that the pool size is set to 6. The ValidationService.fieldAggregator() method is invoked to validate six arguments; consequently, it submits six tasks to the thread pool. Each task submits a corresponding subtask to sanitize the input. The SanitizeInput subtasks must execute before the original six tasks can return their results. However, this is impossible because all six threads in the thread pool are blocked. Furthermore, the shutdown() method cannot shut down the thread pool when it contains active tasks.

Thread-starvation deadlock can also occur when a single-threaded Executor is used, for example, when the caller creates several subtasks and waits for the results.

Compliant Solution (No Interdependent Tasks)

This compliant solution modifies the ValidateInput<V> class so that the SanitizeInput tasks are executed in the same threads as the ValidateInput tasks rather than in separate threads. Consequently, the ValidateInput and SanitizeInput tasks are independent, which eliminates their need to wait for each other to complete. The SanitizeInput class has also been modified to omit implementation of the Callable interface.

Code Block
bgColor#ccccff
public final class ValidationService {
  // ...
  public StringBuilder fieldAggregator(String... inputs)
      throws InterruptedException, ExecutionException {
    // ...
    for (int i = 0; i < inputs.length; i++) {
      // Don't pass-in thread pool  
      results[i] = pool.submit(new ValidateInput<String>(inputs[i])); 
    }
    // ...
  }
}

// Does not use same thread pool
public final class ValidateInput<V> implements Callable<V> { 
  private final V input;

  ValidateInput(V input) {
    this.input = input;
  }

  @Override public V call() throws Exception {
    // If validation fails, throw an exception here
    return (V) new SanitizeInput().sanitize(input);
  }
}

public final class SanitizeInput<V> {  // No longer a Callable task
  public SanitizeInput() {}

  public V sanitize(V input) {
    // Sanitize input and return
    return input;
  }
}

Thread-starvation issues can be partially mitigated by choosing a large thread pool size. However, an untrusted caller can still overwhelm the system by supplying more inputs (see TPS00-J. Use thread pools to enable graceful degradation of service during traffic bursts).

Note that operations that have further constraints, such as the total number of database connections or total ResultSet objects open at a particular time, impose an upper bound on the usable thread pool size, as each thread continues to block until the resource becomes available.

Private static ThreadLocal variables may be used to maintain local state in each thread. When using thread pools, the lifetime of ThreadLocal variables should be bounded by the corresponding task [Goetz 2006]. Furthermore, programs must not use these variables to communicate between tasks. There are additional constraints in the use of ThreadLocal variables in thread pools (see TPS04-J. Ensure ThreadLocal variables are reinitialized when using thread pools for more information).

Noncompliant Code Example (Subtasks)

This noncompliant code example contains a series of subtasks that execute in a shared thread pool [Gafter 2006]. The BrowserManager class calls perUser(), which starts tasks that invoke perProfile(). The perProfile() method starts tasks that invoke perTab(), and in turn, perTab starts tasks that invoke doSomething(). BrowserManager then waits for the tasks to finish. The threads are allowed to invoke doSomething() in any order, provided that count correctly records the number of methods executed.

Code Block
bgColor#FFCCCC
public final class BrowserManager {
  private final ExecutorService pool = Executors.newFixedThreadPool(10);
  private final int numberOfTimes;
  private static AtomicInteger count = new AtomicInteger(); // count = 0

  public BrowserManager(int n) {
    numberOfTimes = n;
  }

  public void perUser() {
    methodInvoker(numberOfTimes, "perProfile");
    pool.shutdown();
  }

  public void perProfile() {
    methodInvoker(numberOfTimes, "perTab");
  }

  public void perTab() {
    methodInvoker(numberOfTimes, "doSomething");
  }

  public void doSomething() {
    System.out.println(count.getAndIncrement());
  }

  public void methodInvoker(int n, final String method) {
    final BrowserManager manager = this;
    Callable<Object> callable = new Callable<Object>() {
      @Override public Object call() throws Exception {
        Method meth = manager.getClass().getMethod(method);
        return meth.invoke(manager);
      }
    };

    Collection<Callable<Object>> collection = 
        Collections.nCopies(n, callable);
    try {
      Collection<Future<Object>> futures = pool.invokeAll(collection);
    } catch (InterruptedException e) {
      // Forward to handler
      Thread.currentThread().interrupt(); // Reset interrupted status
    }
    // ...
  }

  public static void main(String[] args) {
    BrowserManager manager = new BrowserManager(5);
    manager.perUser();
  }
}

Unfortunately, this program is susceptible to a thread-starvation deadlock. For example, if each of the five perUser tasks spawns five perProfile tasks, where each perProfile task spawns a perTab task, the thread pool will be exhausted, and perTab() will be unable to allocate any additional threads to invoke the doSomething() method.

Compliant Solution (CallerRunsPolicy)

This compliant solution selects and schedules tasks for execution, avoiding thread-starvation deadlock. It sets the CallerRunsPolicy on a ThreadPoolExecutor and uses a SynchronousQueue [Gafter 2006]. The policy dictates that when the thread pool runs out of available threads, any subsequent tasks will run in the thread that submitted the tasks.

Code Block
bgColor#ccccff
public final class BrowserManager {
  private final static ThreadPoolExecutor pool =
      new ThreadPoolExecutor(0, 10, 60L, TimeUnit.SECONDS,
                             new SynchronousQueue<Runnable>());
  private final int numberOfTimes;
  private static AtomicInteger count = new AtomicInteger(); // count = 0

  static {
    pool.setRejectedExecutionHandler(
    new ThreadPoolExecutor.CallerRunsPolicy());
  }

  // ...
}

According to Goetz and colleagues [Goetz 2006]:

A SynchronousQueue is not really a queue at all, but a mechanism for managing handoffs between threads. In order to put an element on the SynchronousQueue, another thread must already be waiting to accept the handoff. If no thread is waiting, but the current pool size is less than the maximum, ThreadPoolExecutor creates a new thread; otherwise, the task is rejected according to the saturation policy.

According to the Java API [API 2014], the CallerRunsPolicy class is

a handler for rejected tasks that runs the rejected task directly in the calling thread of the execute method, unless the executor has been shut down, in which case, the task is discarded.

In this compliant solution, tasks that have other tasks waiting to accept the hand-off are added to the SynchronousQueue when the thread pool is full. For example, tasks corresponding to perTab() are added to the SynchronousQueue because the tasks corresponding to perProfile() are waiting to receive the hand-off. Once the pool is full, additional tasks are rejected according to the saturation policy in effect. Because the CallerRunsPolicy is used to handle these rejected tasks, all the rejected tasks are executed in the main thread that started the initial tasks. When all the threads corresponding to perTab() have finished executing, the next set of tasks corresponding to perProfile() are added to the SynchronousQueue because the hand-off is subsequently used by perUser() tasks.

The CallerRunsPolicy allows graceful degradation of service when faced with many requests by distributing the workload from the thread pool to the work queue. Because the submitted tasks cannot block for any reason other than waiting for other tasks to complete, the policy guarantees that the current thread can handle multiple tasks sequentially. The policy would fail to prevent thread-starvation deadlock if the tasks were to block for some other reason, such as network I/O. Furthermore, this approach avoids unbounded queue growth because SynchronousQueue avoids storing tasks indefinitely for future execution, and all tasks are handled either by the current thread or by a thread in the thread pool.

This compliant solution is subject to the vagaries of the thread scheduler, which might schedule the tasks suboptimally. However, it avoids thread-starvation deadlock.

Risk Assessment

Executing interdependent tasks in a thread pool can lead to denial of service.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

TPS01-J

Low

Probable

Medium

P4

L3

Bibliography

[API 2014]

Class CallerRunsPolicy

[Gafter 2006]

A Thread Pool Puzzler

[Goetz 2006]

Section 5.3.3, "Dequeues and Work Stealing"
Section 8.3.2, "Managing Queued Tasks"
Section 8.3.3, "Saturation Policies"

 

...

Image Added Image Added Image Added