Java: Concurrency

Thread life-cycle

new: the thread is newly begun.

runnable: the thread is executing its task.

waiting: the thread waits for another thread to perform a task. When another thread notifies it to continue, it transitions back to runnable.

timed waiting:

1) A runnable thread transitions to timed waiting if it provides an optional wait interval when waiting for another thread to perform a task. When the thread is notified by another thread or when the specified timed interval expires – whichever comes first, it returns to runnable.

2) A runnable thread also transitions to timed waiting if it is put to sleep for a designated sleep interval, after which it returns to runnable.

blocked: A runnable thread transitions to blocked when it attempts to perform a task (e.g. I/O request) that cannot be completed immediately and it must temporarily wait until that task completes.

Timed waiting, waiting and blocked threads cannot use a processor even if one is available.

terminated: a.k.a. dead. A runnable thread transitions to terminated when it successfully completes its task or otherwise terminates (e.g. due to an error).

Operating-system view of Runnable state

The transition between ready and running states are handled solely by OS, JVM simply views them as runnable.

Ready: when a thread first transitions to runnable from the new state.

Running: A ready thread transitions to running when OS assigns it to a processor (i.e. dispatching the thread).

In most OSs, each thread is given a quantum (a.k.a. timeslice) to perform its task, when its quantum expires the thread returns to ready, and OS assigns another thread to the processor.

Runnable 

public class YourTask implements Runnable {
    
    public YourTask() {
        /*constructor*/
    }
    
    public void run() {
        try {
            /*perform task */
            Thread.sleep(sleepTime);//put to sleep
        } catch (InterruptedException exception) {
            exception.printStackTrace();
            Thread.currentThread().interrupt();
        }
    }
    
}

public static void main(String[] args) {
    YourTask task1=new PrintTask("task1");
    YourTask task2=new PrintTask("task2");
    YourTask task3=new PrintTask("task3");
        
    ExecutorService executorService=Executors.newCachedThreadPool();
        
    executorService.execute(task1);
    executorService.execute(task2);
    executorService.execute(task3);
        
    executorService.isShutdown();
}

Executor Framework

e.g.

public class YourTask implements Runnable {
    
    public YourTask() {
        /*constructor*/
    }
    
    public void run() {
        try {
            /*perform task */
Thread.sleep(sleepTime);//put to sleep
/* sleep is called only for demonstration cuz normally it’s unpredictable when and how long will  each threa perform its task. */
        } catch (InterruptedException exception) {
            exception.printStackTrace();
            Thread.currentThread().interrupt();
        }
    }
    
}

public static void main(String[] args) {
    PrintTask task1=new yourTask("task1");
    PrintTask task2=new yourTask("task2");
    PrintTask task3=new yourTask("task3");
    System.out.println("Starting Executor");
    
    ExecutorService executorService=Executors.newCachedThreadPool();
    
    executorService.execute(task1);
    executorService.execute(task2);
    executorService.execute(task3);
    
    executorService.isShutdown();
       executorService.awaitTermination(1, TimeUnit.MINUTES); 
}

Runnable interface

specifies a task to execute concurrently with other tasks.

run() contains the task to perform.

Executor Interface

,executes Runnable objects, manages a thread pool.

execute() accepts argument Runnable, which will be passed to one of the available threads (to perform its run()) in the thread pool.

ExecutorService interface

Extends Executor.

Obtained by calling class Executors’static method newCachedThreadPool().

shutdown() notifies the ExecutorService to stop accepting new tasks but continue executing tasks that have already been submitted.

awaitTermination() returns control to its caller either when all tasks executing in the ExecutorService complete (return true) or when the specified timeout elapses(return false). Can be used to ask the main thread to wait for scheduled tasks to complete (because in practice main thread can terminates early while other threads of the program can continue executing).

Producer-Consumer

//home-made interface Buffer shared by Producer and Consumer threads
public interface Buffer {
    //called by Producer
    public void blockingPut(int value) throws InterruptedException;
    //called by Consumer
    public int blockingGet() throws InterruptedException;
}

Java.util.concurrent -- use encapsulated synchronization class

Classes from java.util.concurrent encapsulate the synchronization.

ArrayBlockingQueue: A fully implemented thread-safe buffer class that implement interface BlockingQueue.

put() places an element at the end of the BlockingQueue, waiting if the queue is full.

take() removes an element from the head of the BlockingQueue, waiting if the queue is empty.

import java.util.concurrent.ArrayBlockingQueue; 

public class BlockingBuffer implements Buffer {

    private final ArrayBlockingQueue<Integer> buffer;
    
    public BlockingBuffer() {
        buffer=new ArrayBlockingQueue<Integer>(1);
    }
    
    public void blockingPut(int value) throws InterruptedException {
        buffer.put(value);
        /* other operations
        ...
        */
    }
    
    public int blockingGet() throws InterruptedException {
        int readValue=buffer.take();
        /* other operations
        ...
        */
        return readValue;
    }
}

 Monitors: synchronized, wait, notify & notifyAll

Every object has a monitor and a monitor lock. The monitor ensures that the object’s monitor lock is held by a maximum of 1 thread at any time.

synchronized

synchronized (object) { //object is normally ‘this’
    /* statements */
}

code placed in a synchronized statement is guarded by the monitor lock, a thread must acquire the lock to execute the guarded statements.

synchronized methods

Before executing, a synchronized instance method must acquire the lock on the object used to call the method.

A static synchronized method must acquire the lock on the class used to call the method.

Place all access to mutable data that may be shared by multiple threads inside synchronized statement or synchronized methods.

Keep the duration of synchronized statement as short as possible to minimize the wait time for blocked thread. E.g. avoid performing I/O, length calculation.

wait(): When a thread holding the monitor lock on an object determines that it cannot continue its task until some condition is satisfied, it call wait() on the synchronized obj to release the monitor lock on the synchronized object, then the thread switches to waiting state while other threads can enter the obj’s synchronized statements/methods.

notify(): When a thread executing a synchronized statement/method completes or satisfies the condition on which another thread may be waiting, it can call notify() on the synchronized obj to allow a waiting thread to transition to runnable again.

notifyAll(): If a thread call notifyAll() on the synchronized obj, all threads waiting for that monitor lock become eligible to reaquire the lock.

e.g.

public class SynchronizedBuffer implements Buffer {
    
    private int buffer=-1;
    private boolean occupied=false;
    
    public synchronized void blockingPut(int value) throws InterruptedException {
        //when there are no empty location, place thread in waiting state
        while (occupied) {
            System.out.println("Producer tries to write.");
            displayState("Buffer full. Producer waits.");
            wait();
        }
        //put value
        buffer=value;
        occupied=true;
        displayState("Producer writes "+buffer);
        //tell waiting threads to enter runnable state
        notifyAll();
    } //release lock on SynchronizedBuffer
    
    public synchronized int blockingGet() throws InterruptedException {
        //when there's no data to read, place thread in waiting state
        while (!occupied) {
            System.out.println("Consmer tries to read.");
            displayState("Buffer empty. Consumer waits.");
            wait();
        }
        //retrieve value
        occupied=false;
        displayState("Consumer reads "+buffer);
        //tell waiting threads to enter runnable state
        notifyAll();
        return buffer;
    } //release lock on SynchronizedBuffer
    
    private synchronized void displayState(String operation) {
        System.out.printf("%-40s%d		%b%n%n", operation,buffer,occupied);
    }
}

Lock & Condition

Lock interface

lock() & unlock(): A thread calls Locks’s lock() method to acquire the lock. Once a Lock has been obtained by one thread, the Lock object will not allow another thread to obtain the Lock until the first thread releases the Lock (by calling the Lock’s unlock() method).

Place unlock() in a finally block so that if an exception is thrown unlock must still be called.

ReentrantLock: a class that is a basic implementation of Lock. Its constructor takes a Boolean argument that specifies fairness policy – true: “the longest-waiting thread will acquire the lock when it’s available”(avoids indefinite postpone); false: no guarantee as to which waiting thread will acquire the lock when it’s available.

newCondition(): returns an object that implements Condition interface that are associated with that specific Lock.

Condition interface

If a thread that owns a Lock determines that it cannot continue with its task until some condition is satisfied, the thread can wait on a condition object.

await(): A thread can call the Condition’s await(), this immediately releases the associated Lock and places the thread in waiting state for that Condition object.

signal(): When a runnable thread completes its task, it can call Condition method signal() to allow a thread in that Condition’s waiting state to return to runnable.

signalAll(): If a thread calls Condition method signalAll(), all threads waiting for that condition transition to runnable state, only one of them can obtain the Lock and other will wait again.

e.g. /* somehow it does not work properly in Windows 10 because the lock isn’t released when the thread await on a condition, I don’t know why. It works fine in MAC OS X. */ 

public class SynchronizedBuffer implements Buffer {

    private final Lock accessLock=new ReentrantLock();
    private final Condition canWrite=accessLock.newCondition();
    private final Condition canRead=accessLock.newCondition();
    private int buffer=-1;
    private boolean occupied=false;
    
    public void blockingPut(int value) throws InterruptedException {
        accessLock.lock(); //lock this object
        try {
            while (occupied) {
                System.out.println("Producer tries to write.");
                displayState("Buffer full. Producer waits.");
                canWrite.await(); //wait until buffer is empty
            }
            buffer=value;
            occupied=true;
            displayState("Producer writes "+buffer);
            canRead.signalAll();
        } finally {
            accessLock.unlock();
        }
    }
    
    public int blockingGet() throws InterruptedException {
        int readValue=0;
        accessLock.lock();
        try {
            //if there's no data to read, place the thread in waiting state
            while (!occupied) {
                System.out.println("Consumer tries to read.");
                displayState("Buffer empty. Consumer waits.");
                canRead.await();//wait on Condition canRead (full buffer) also release the lock implicitly
            }
            occupied=false;
            readValue=buffer;
            displayState("Consumer reads "+readValue);
            //signal any threads waiting for Condition canWrite (empty buffer)
            canWrite.signalAll();
        } finally {
            accessLock.unlock();
        }
        return readValue;
    }
    
    private void displayState(String operation) {
        try {
            accessLock.lock();
            System.out.printf("%-40s%d		%b%n%n", operation,buffer,occupied);
        } finally {
            accessLock.unlock();
        }
    }
    
}

SwingWorker – Multithreading with GUI

event dispatch thread: All Swing applications have this single thread to handle interaction with the application’s GUI components. All tasks that require interaction with an application’s GUI are placed in an event queue and are executed sequentially by the event dispatch thread.

Swing GUI component are not thread safe. Thread safety in GUI application is achieved not by synchronizing thread action, but by thread confinement.

Thread confinement: Allowing just one thread (the event dispatch thread) to access Swing components.

Problem: If an application must perform a lengthy computation in response to a user interaction, the event dispatch thread cannot attend to other tasks in the event queue while computation, this causes the GUI component to be unresponsive.

Solution: to handle a long-running computation in a separate thread, freeing the event dispatch thread to continue managing other GUI interactions.

SwingWorker<T,V> class: implements Runnable. When execute() is called, the object will be scheduled to perform an asynchronous task in a worker thread then update Swing components from the event dispatch thread based on the task’s results. 

T – the type returned by doInBackground().

V – the type passed between publish() and process() to handle intermediate results.

The GUI components that will be manipulated by SwingWorker methods (e.g. process() or done()) should be passed to the SwingWorker subclass’s constructor and stored in the subclass object.

doInBackground() defines a long computation and is called in a worker thread.

done() executes on the event dispatch thread when doInBackground() returns.

execute() schedules the SwingWorker object to be executed in a worker thread.

get() waits for the result to be ready if necessary. 

publish() sends intermediate results from doInBackground() to process().

process() receives intermediate results from publish() and processes them on the event dispatch thread.

setProgress() sets the progress property to notify any property change listener on the event dispatch thread of progress bar updates.

e.g. use SwingWorker subclass to perform background calculation

public class BackgroundCalculator extends SwingWorker<Long, Object> {
    
    private final JLabel resultJLabel; //some related UI object
    
    public BackgroundCalculator(int n, JLabel resultJLabel) {
        //constructor
    }
    
    public Long doInBackground() {
        //long-running task to performed in a worker thread
    }
    
    protected void done() {
        //code to run on the event dispatch thread when doinBackground returns
        try {
            //get the result of doInBackground and display it
            
            resultJLabel.setText(get().toString());
        } catch (InterruptedException ex) {
            /* if the current thred is interrupted while waiting for get() to return.
But Since we call get() from done(), the computation will be complete before get() is called
Thus this exception will not occur in this example. */
        } catch (ExecutionException ex) {
            /* if an exception occurs during the computation */
        }
    }

}

public class FibonacciNumbers extends JFrame {
    //button to activate the swingWorker subclass's task
    private final JButton goJButton=new JButton("Go");
    //ui component connected to the swingWorker subclass
    private final JLabel fibonacciJLabel=new JLabel();
    
    //Constructor
    public FibonacciNumbers() {
        /* super, setLayout, ...etc */
        goJButton.addActionListener(
            new ActionListener() {
                public void ActionPerformed(ActionEvent event) {
                    /* retrieve user's input as swingWorker subclass's input
                    e.g. integer n. */
                    //create a task to perform calculation in background
                    BackgroundCalculator task=new BackgroundCalculator(n, fibonacciJLabel);
                    task.execute(); //execute the task
            });
        /* add GUI components, etc.*/
        
        
    }
    
}

e.g. update the GUI with intermediate results before the long calculation completes.

-- using publish(), process() and setProgress().

publish() -> sends prime numbers to process() as they’re found;

process() -> displays found primes in a GUI component;

setProgress() -> updates the progress property.

public class PrimeCalculator extends SwingWorker<Integer, Integer> {
    
    /* GUI components & arrays for finding primes */
    private final boolean[] primes;
    
    //constructor
    public PrimeCalculator(int max, JTextArea intermediateJTextArea,
        JLabel statusJLabel, JButton getPrimesJButton,
        JButton cancelJButton) {
        /* stores parameters GUI component inside */
    }
    
    //calculation: find all primes up to max
    public Integer doInBackground() {
        //...
        if (isCancelled())
            return count;
        else {
            /* ... */
            /*put the worker thread to sleep for a few milliseconds between calls to publish()
            thus slow down the calculation and event dispatch thread can keep up with requests of update.
            Because too many requests piling up on the event dispatch thread will cause event queue out of memory.
             
            */
            Thread.sleep();
            //during calculation, set progress according to count of found primes
            setProgress(100*(i+1)/primes.length);    
            //during calculation, make a found prime i available for displaying an intermediate result
            publish(i);
        }
        /* ... */
    }
    
    //display found primes in a GUI component
    protected void process(List<Integer> publishedVals) {
        for (int i=0;i<publishedVals.size();i++)
            intermediateJTextArea.append(publishedVals.get(i)+"
");
    }
    
    //code to execute when doInBackground completes
    protected void done() {
        /* ... */
    }
        
}

-- In JFrame subclass, add PropertyChangeListener for the SwingWorker subclass to listen for progress changes.

public class FindPrimes extends JFrame {

    //GUI components & the SwingWorker subclass
    private final JProgressBar progressJProgressBar=new JProgressBar();
    private PrimeCalculator calculator;
    
    //Consturctor
    public FindPrimes() {
        /* ...
        * Initialization
        * & reset GUI components
        * & get user input */
        //inside the actionPerformed() event listener method of the start button,
        //construct a new SwingWorker subclass object
        calculator = new PrimeCalculator(number,displayPrimesJTextArea,
            statusJLabel, getPrimesJButton, cancelJButton);
        //listen for progress bar property changes
        calculator.addPropertyChangeListener(
            new PropertyChangeListener() {
                public void propertyChange(PropertyChangeEvent e) {
                    //if the changed property is progress, update the progresss bar
                    if (e.getPropertyName().contentEquals("progress")) {
                        int newValue=(integer)e.getNewValue();
                        progressJProgressBar.setValue(newValue);
                    }
                }
            });
            calculator.execute();
    }
    
}

Parallel Sort & Parallel Stream

ParallelSort()

For sorting large arrays on multi-core systems, Arrays.parallelSort() is more efficient than Arrays.sort().

Can compare the efficiency by Date/Time API:

e.g.

Instant sortStart=Instant.now();
Arrays.sort(array1);
Instant sortEnd=Instant.now();
long sortTime=Duration.between(sortStart,sortEnd).toMillis();
Instant parallelSortStart=Instant.now();
Arrays.sort(array2);
Instant parallelSortEnd=Instant.now();
long parallelSortTime=Duration.between(parallelSortStart,parallelSortEnd).toMillis();
String percentage=NumberFormat.getPercentInstance().format((double)sortTime/parallelSortTime);

Parallel Stream

Invoke parallel() on an existing stream to obtain a parallel stream thus enhance performance on multi-core system.

Long stream stream2=Arrays.stream(values).parallel():

Interface Callable

Problem: Runnable’s run() cannot return a value, would require shared mutable data to pass the value back if the calling thread needs it.

Solution: Callable.

Callable interface

call(): returns a value representing the result of its task.

ExecutorService interface

submit(): executes its Callable argument and returns an object of type Future.

Future interface

Represents the Callable’s future result.

get(): blocks the calling thread and waits for the Callable to complete and return its result.

Also provides methods that cancel a Callable’s execution/determine whether Callable was cancelled/determine whether the Callable completed its task.

CompletableFuture class

Implements the Future interface. Can asynchronously execute Runnables or Suppliers.

e.g.

//perform synchronous calculation tasks fibonacci()
//TimeData is the specific return type of fibonacci()
TimeData synchronousResult1=startFibonacci(45);
TimeData synchronousResult2=startFibonacci(44);
         
//perform asynchronous calculation tasks fibonacci()
CompletableFuture<TimeData> futureResult1=
                CompletableFuture.supplyAsync(()->startFibonacci(45));
CompletableFuture<TimeData> futureResult2=
                CompletableFuture.supplyAsync(()->startFibonacci(44));
//wait for results from the asynchronous operations
TimeData asynchronousResult1=futureResult1.get();
TimeData asynchronousResult2=futureResult2.get();