5 things about java.util.concurrent you don't know, part 2nd

Concurrent collections provides thread-safe, well tuned data structures, and simplifies concurrent programming. However, in some cases, developers need to take a step further and think about how to adjust and/or restrict thread execution. Because the overall goal of Java.util.concurrent is to simplify multithreaded programming, you might want the package to contain the synchronization utility, which it does contain.

This article is a continuation of part 1th, which will introduce several more advanced synchronization structures than the core language primitives (monitors), but they are not yet included in the Collection class. Once you understand the use of these locks and doors, it is very intuitive to use them.

1. Semaphore

In some enterprise systems, developers often need to limit the number of unhandled specific resource requests (threads/operations), and in fact, constraints can sometimes improve system throughput because they reduce contention for specific resources. Although it is entirely possible to write the restriction code manually, using the semaphore class makes it easier to accomplish this task, which will help you enforce the restrictions, as shown in Listing 1:

Listing 1. Using semaphore to enforce restrictions

Import Java.util.*;import java.util.concurrent.*;

public class Semapp
{
public static void Main (string[] args)
{
Runnable Limitedcall = new Runnable () {
Final Random rand = new Random ();
Final semaphore available = new semaphore (3);
int count = 0;
public void Run ()
{
int time = Rand.nextint (15);
int num = count++;

Try
{
Available.acquire ();

SYSTEM.OUT.PRINTLN ("executing" +
"Long-running Action for" +
Time + "seconds ... #" + num);

Thread.Sleep (time * 1000);

System.out.println ("Done with #" +
num + "!");

Available.release ();
}
catch (Interruptedexception intEx)
{
Intex.printstacktrace ();
}
}
};

for (int i=0; i<10; i++)
New Thread (Limitedcall). Start ();
}
}

Even if the 10 threads in this example are running (you can perform jstack validation on the Java process running Semapp), only 3 threads are active. The other 7 threads are idle until one of the signal counters is released. (In fact, the semaphore class supports fetching and releasing multiple permit at once, but this does not apply to this scenario.) ）