Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

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

...

Sub-tasks)

...

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

...

sub-task

...

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 class ValidationService {
  private final ExecutorService pool;

  public ValidationService(int poolSize) {
    pool = Executors.newFixedThreadPool(poolSize);
  }

  public void shutdown() {
    pool.shutdown();
  }

  public StringBuilder fieldAggregator(String... inputs)
      throws InterruptedException, ExecutionException {

    StringBuilder sb = new StringBuilder();
    // Stores the results
    Future<String>[] results = new Future[inputs.length]; 

    // Submits the tasks to thread pool
    for (int i = 0; i < inputs.length; i++) { 
      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 V input;
  private final ExecutorService pool;

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

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

public final class SanitizeInput<V> implements Callable<V> {
  private final V input;

  SanitizeInput(V 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(6); 
System.out.println(vs.fieldAggregator("field1", "field2", "field3", "field4", "field5", "field6")); 
vs.shutdown(); 
} 
{mc}

Assume, for example, that the pool size is set to six. The {{ValidationService.fieldAggregator()}} method is invoked to validate six arguments; consequently, it submits six tasks to the thread pool. Each task submits a corresponding sub-task to sanitize the input. The {{SanitizeInput}} sub-tasks 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 sub-tasks and waits for the results.


h2. 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; this 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:bgColor=#ccccff}
public final class ValidationService {
  // ...
  public StringBuilder fieldAggregator(String... inputs)
      throws InterruptedException, ExecutionException

Assume, for example, that the pool size is set to six. The ValidationService.fieldAggregator() method is invoked to validate six arguments; consequently, it submits six tasks to the thread pool. Each task submits a corresponding sub-task to sanitize the input. The SanitizeInput sub-tasks 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 sub-tasks 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; this 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 foran (intexception ihere
 = 0; i < inputs.length; i++) {
     return (V) new SanitizeInput().sanitize(input);
  }
}

public final class SanitizeInput<V> {  // Don't pass-in thread pool  No longer a Callable task
  public SanitizeInput() {}

  results[i] = pool.submit(new ValidateInput<String>(inputs[i])); public V sanitize(V input) {
    }
    // ...
Sanitize  }
}

// 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;
  }
}
{code}

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 rule [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|AA. References#Goetz 06]\]. 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 rule [TPS04-J. Ensure ThreadLocal variables are reinitialized when using thread pools] for more information.


h2. Noncompliant Code Example (Sub-tasks)

{mc} 
h2. Compliant Solution (Unbounded Thread Pool)
This compliant solution uses a cached thread pool, which dynamically creates new threads as needed and prevents deadlock. However, this implementation can result in resource exhaustion and should not be used in front-end or critical production systems. 

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

public ValidationService(int poolSize) { 
pool = Executors.newCachedThreadPool(); 
} 
// ... 
} 
{code} 

According to the Java API \[[API 2006|AA. Java References#API 06]\], the {{Executors.newCachedThreadPool()}} method 

{quote} 
Creates a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available. These pools will typically improve the performance of programs that execute many short-lived asynchronous tasks. Calls to execute will reuse previously constructed threads if available. If no existing thread is available, a new thread will be created and added to the pool. Threads that have not been used for sixty seconds are terminated and removed from the cache. Consequently, a pool that remains idle for long enough will not consume any resources. 
{quote} 
{mc}

This noncompliant code example contains a series of subtasks that execute in a shared thread pool  \[[Gafter 2006|AA. References#Gafter 06]\].  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: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();
  }
}
{code}

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.


h2. Compliant Solution ({{CallerRunsPolicy}})

{mc}To prevent thread starvation, every level (worker) must have a double-ended queue, where all sub-tasks are queued \[[Goetz 2006|AA. Java References#Goetz 06]\]. 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 (work stealing). {mc}

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|AA. References#Gafter 06]\]. 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: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());
  }

  // ...
}
{code}

According to Goetz and colleagues \[[Goetz 2006|AA. References#Goetz 06]\]

{quote}
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.
{quote}

According to the Java API \[[API 2006|AA. References#API 06]\], the {{CallerRunsPolicy}} class is

{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}

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 handoff 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.


h2. 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 | {color:green}{*}P4{*}{color} | {color:green}{*}L3{*}{color} |


h2. Bibliography

| \[[API 2006|AA. References#API 06]\] | |
| \[[Gafter 2006|AA. References#Gafter 06]\] | [A Thread Pool Puzzler|http://gafter.blogspot.com/2006/11/thread-pool-puzzler.html] |
| \[[Goetz 2006|AA. References#Goetz 06]\] | 8.3.2, Managing queued tasks; 8.3.3, Saturation Policies; 5.3.3, Dequeues and work stealing |

----
[!The CERT Oracle Secure Coding Standard for Java^button_arrow_left.png!|TPS00-J. Use thread pools to enable graceful degradation of service during traffic bursts]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[!The CERT Oracle Secure Coding Standard for Java^button_arrow_up.png!|10. Thread Pools (TPS)]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[!The CERT Oracle Secure Coding Standard for Java^button_arrow_right.png!|TPS02-J. Ensure that tasks submitted to a thread pool are interruptible]

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 rule 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 rule TPS04-J. Ensure ThreadLocal variables are reinitialized when using thread pools for more information.

Noncompliant Code Example (Sub-tasks)

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 2006], 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 handoff 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 2006]

 

[Gafter 2006]

A Thread Pool Puzzler

[Goetz 2006]

8.3.2, Managing queued tasks; 8.3.3, Saturation Policies; 5.3.3, Dequeues and work stealing

...

Image Added      10. Thread Pools (TPS)      Image Added