DEV Community: Shreyans

Java Concurrency : Future

Shreyans — Tue, 12 Sep 2023 02:30:00 +0000

In my previous post in this series, I talked about the concept of a Callable in Java. We saw that when we execute a Callable task using the ExecutorService, we get back a Future<T>. What is this 'Future' ? In the previous post in this series, you have already seen basic usage of Futures. In this post, we'll discuss two of the most important methods detailed out in the Future API.

In simple words, a Future is a placeholder for the result of an asynchronous computation that is to be performed some time in the future. It is used as a reference to the result of an asynchronous computation.

T get()

This method can be used to 'get' the result of the asynchronous computation. The callable task can be in any of the many possible states when you invoke this method on the corresponding future. Three of the most basic possible scenarios is

Still RUNNING
Normal COMPLETION
Exceptional COMPLETION

The following code snippet shows each of these scenarios in action. Notice how when our callable is still running, the .get() call blocks the main thread.

    public static void main(String[] args) {
        System.out.println("Main method has started.");

        ExecutorService executorService = Executors.newFixedThreadPool(3);

        Future<Integer> stillRunning = executorService.submit(new Task(2000, false));
        Future<Integer> normalCompletion = executorService.submit(new Task(20, false));
        Future<Integer> exceptionalCompletion = executorService.submit(new Task(20, true));

        try {
            long startEpoch = System.currentTimeMillis();
            Integer resultStillRunning = stillRunning.get();
            long endEpoch = System.currentTimeMillis();

            System.out.println("[1] Result : " + resultStillRunning);
            System.out.println("[1] Time Taken For .get() call : " + (endEpoch - startEpoch));
        } catch (InterruptedException e) {
            System.out.println("[1] InterruptedException");
        } catch (ExecutionException e) {
            System.out.println("[1] ExecutionException : " + e.getCause().getMessage());
        }


        try {
            long startEpoch = System.currentTimeMillis();
            Integer resultNormalCompletion = normalCompletion.get();
            long endEpoch = System.currentTimeMillis();

            System.out.println("[2] Result : " + resultNormalCompletion);
            System.out.println("[2] Time Taken For .get() call : " + (endEpoch - startEpoch));
        } catch (InterruptedException e) {
            System.out.println("[2] InterruptedException");
        } catch (ExecutionException e) {
            System.out.println("[2] ExecutionException : " + e.getCause().getMessage());
        }


        try {
            long startEpoch = System.currentTimeMillis();
            Integer resultExceptionalCompletion = exceptionalCompletion.get();
            long endEpoch = System.currentTimeMillis();

            System.out.println("[3] Result : " + resultExceptionalCompletion);
            System.out.println("[3] Time Taken For .get() call : " + (endEpoch - startEpoch));
        } catch (InterruptedException e) {
            System.out.println("[3] InterruptedException");
        } catch (ExecutionException e) {
            System.out.println("[3] ExecutionException : " + e.getCause().getMessage());
        }

        executorService.shutdown();

        System.out.println("Main method has finished.");
    }

    private static class Task implements Callable<Integer> {

        private final int sleepForMilliseconds;
        private final boolean throwException;

        public Task(int sleepForMilliseconds, boolean throwException) {
            this.sleepForMilliseconds = sleepForMilliseconds;
            this.throwException = throwException;
        }

        @Override
        public Integer call() throws Exception {
            if (throwException) {
                throw new Exception("Something bad happened...");
            }

            TimeUnit.MILLISECONDS.sleep(sleepForMilliseconds);
            return new Random().nextInt();
        }
    }

The output is

Main method has started.
[1] Result : 1548882964
[1] Time Taken For .get() call : 2005
[2] Result : 1474341827
[2] Time Taken For .get() call : 0
[3] ExecutionException : Something bad happened...
Main method has finished.

boolean isDone()

This method returns true if this task 'completed'. Completion may be due to normal or exceptional. Also, while we will not be discussing cancelling of tasks in this post, the isDone() method returns true even when the task was cancelled.

The following code snippet shows this method in action.

    public static void main(String[] args) throws ExecutionException, InterruptedException {
        System.out.println("Main method has started.");

        ExecutorService executorService = Executors.newFixedThreadPool(3);

        Future<Integer> future = executorService.submit(new Task());

        while (!future.isDone()) {
            System.out.println("Task Is Still Not Done!");
            Thread.sleep(6L); // busy-waiting (just for demonstration, bad idea in production code)
        }
        System.out.println("Task Is Done With Result : " + future.get());

        executorService.shutdown();

        System.out.println("Main method has finished.");
    }

    private static class Task implements Callable<Integer> {

        @Override
        public Integer call() throws Exception {
            TimeUnit.MILLISECONDS.sleep(20);
            System.out.println("Task Completed!");
            return new Random().nextInt();
        }
    }

The output is

Main method has started.
Task Is Still Not Done!
Task Is Still Not Done!
Task Is Still Not Done!
Task Is Still Not Done!
Task Completed!
Task Is Done With Result : 1549778552
Main method has finished.

Java Concurrency : Callable

Shreyans — Mon, 11 Sep 2023 06:39:00 +0000

In the last post in this series, we understood what a Runnable is in Java. Some of you may have noticed a big limitation of the Runnable API, that it does not return a value. This means that while you can use a Runnable to execute some unit of work in a separate thread, there isn't a straightforward way for you to retrieve a meaningful value which may represent the result of that work.

For the reader's understanding, the code below shows one way how you might retrieve the result of a Runnable. However, please note that this is just for your understanding and you will not find code like this in production grade applications.

    public static void main(String[] args) {
        System.out.println("Main method has started.");

        BlockingQueue<String> resultsHolder = new ArrayBlockingQueue<String>(10);

        new Task(resultsHolder);
        new Task(resultsHolder);
        new Task(resultsHolder);

        try {
            System.out.println(resultsHolder.take());
            System.out.println(resultsHolder.take());
            System.out.println(resultsHolder.take());
        } catch (InterruptedException e) {
            // thrown when current thread was interrupted while waiting on the blocking call .take()
            throw new RuntimeException(e);
        }

        System.out.println("Main method has finished.");
    }

    private static class Task extends Thread {

        private static int numTasks;
        private final int id;
        private final BlockingQueue<String> resultsHolder;

        public Task(BlockingQueue<String> resultsHolder) {
            this.id = ++numTasks;
            this.resultsHolder = resultsHolder;
            this.start();
        }

        @Override
        public void run() {
            System.out.println("Task has started.");

            try {
                TimeUnit.MILLISECONDS.sleep(2000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }

            String result = "Hello, World! This is Task : " + id;
            this.resultsHolder.add(result);

            System.out.println("Task has finished.");
        }
    }

Java Concurrency Framework provides the Callable interface. Along with certain other differences and advantages (more about this in another post), It solves the above mentioned limitation of Runnable.

To execute a Callable task, you can use an ExecutorService to get a Future representing the result of the task. (More about Future and ExecutorService in another post)

    public static void main(String[] args) {
        System.out.println("Main method has started.");

        Task t1 = new Task();
        Task t2 = new Task();
        Task t3 = new Task();

        ExecutorService executorService = Executors.newFixedThreadPool(3);

        Future<String> f1 = executorService.submit(t1);
        Future<String> f2 = executorService.submit(t2);
        Future<String> f3 = executorService.submit(t3);

        try {
            System.out.println(f1.get());
            System.out.println(f2.get());
            System.out.println(f3.get());
        } catch (InterruptedException e) {
            // thrown when current thread was interrupted
            // while waiting on the blocking call .get()
            throw new RuntimeException(e);
        } catch (ExecutionException e) {
            // thrown when attempting to retrieve the result
            // of a task that aborted by throwing an exception.
            throw new RuntimeException(e);
        }

        executorService.shutdown();

        System.out.println("Main method has finished.");
    }

    private static class Task implements Callable<String> {

        private static int numTasks;
        private final int id;

        public Task() {
            this.id = ++numTasks;
        }

        @Override
        public String call() {
            System.out.println("Task has started.");

            try {
                TimeUnit.MILLISECONDS.sleep(2000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }

            return "Hello, World! This is Task : " + id;
        }
    }

The output is

Main method has started.
Task has started.
Task has started.
Task has started.
Hello, World! This is Task : 1
Hello, World! This is Task : 2
Hello, World! This is Task : 3
Main method has finished.

In addition to Callables, An ExecutorService can also be used for executing Runnables.

The ExecutorService provides these methods for this purpose. Do check these out!

void execute(Runnable command) [Java Doc Link]
Future<?> submit(Runnable task) [Java Doc Link]

Java Concurrency : Runnable

Shreyans — Sun, 10 Sep 2023 07:29:18 +0000

Brief Introduction

In Java, a Runnable is an interface that represents a unit of work which can be executed by a thread. It is part of the Java Concurrency framework (java.util.concurrent).

Example - A Runnable Task

    public class Task implements Runnable {

        @Override
        public void run() {
            // do something meaningful
            System.out.println("Hello, World!");
        }
    }

Example - A Thread running a Runnable Task

The Java Concurrency Framework provides a Thread class which can be used for running a Runnable in a separate thread of execution. This can be done by using the start() method provided by the Thread class which initiates the execution of the thread's code in a new thread of control. This method is essential for multithreading because it tells the Java Virtual Machine (JVM) to begin executing the run() method of the underlying Runnable concurrently in a separate thread.

    public static void main(String[] args) {
        System.out.println("Main method has started.");

        Thread t = new Thread(new Task("Charlie"));
        t.start();

        System.out.println("Main method has finished.");
    }

    private static class Task implements Runnable {

        private final String name;

        public Task(String name) {
            this.name = name;
        }

        @Override
        public void run() {
            System.out.println("Task " + name + " has started.");
            System.out.println("Hello, World! This is Task : " + name);
            System.out.println("Task " + name + " has finished.");
        }
    }

The output of this program is non deterministic. This is because the operating system and the Java Virtual Machine (JVM) schedule and manage thread execution independently, and the order in which threads (in this case the main thread and the explicitly created task thread) are scheduled to run can vary each time the program is executed.

For instance, one possible output is

Main method has started.
Main method has finished.
Task Charlie has started.
Hello, World! This is Task : Charlie
Task Charlie has finished.

As we are storing the thread reference of the task thread in the main method, we can also wait for its completion before proceeding further in the main method. This can be done by using the join() method provided by the Thread class which is a blocking call and blocks the caller thread until the callee thread completes execution and dies.

    public static void main(String[] args) throws InterruptedException {
        System.out.println("Main method has started.");

        Thread t = new Thread(new Task("Charlie"));
        t.start();
        t.join();

        System.out.println("Main method has finished.");
    }

    private static class Task implements Runnable {

        private final String name;

        public Task(String name) {
            this.name = name;
        }

        @Override
        public void run() {
            System.out.println("Task " + name + " has started.");
            System.out.println("Hello, World! This is Task : " + name);
            System.out.println("Task " + name + " has finished.");
        }
    }

Note how we've also added the InterruptedException to the main method's signature. That is because the join() method of the Thread class throws this checked exception. More about this in another post, but in summary When you call the join() method on a thread (let's call it "Thread 1") from another thread (let's call it "Thread 2"), Thread 2 will wait until Thread 1 completes its execution. In other words, Thread 2 will be blocked until Thread 1 finishes. If, while Thread 2 is waiting, another thread (let's call it "Thread 3") interrupts Thread 2 (e.g., by invoking Thread.interrupt() on Thread 2), Thread 2 will throw an InterruptedException.

The output of this program in this case is deterministic.

Main method has started.
Task Charlie has started.
Hello, World! This is Task : Charlie
Task Charlie has finished.
Main method has finished.

Miscellaneous Example

    public static void main(String[] args) {
        System.out.println("Main method has started.");

        for (int i=0; i<5; ++i) {
            new Task();
        }

        System.out.println("Main method has finished.");
    }

    private static class Task extends Thread {

        private static int numTasks = 0;
        private final int id;

        public Task() {
            this.id = ++numTasks;
            this.start();
        }

        @Override
        public void run() {
            System.out.println("Task " + id + " has started.");

            try {
                TimeUnit.MILLISECONDS.sleep(2000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }

            System.out.println("Hello, World! This is Task : " + id);

            try {
                TimeUnit.MILLISECONDS.sleep(2000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }

            System.out.println("Task " + id + " has finished.");
        }
    }

The output for this is again non-deterministic. One possible output is

Main method has started.
Main method has finished.
Task 5 has started.
Task 2 has started.
Task 4 has started.
Task 1 has started.
Task 3 has started.
Hello, World! This is Task : 4
Hello, World! This is Task : 5
Hello, World! This is Task : 1
Hello, World! This is Task : 2
Hello, World! This is Task : 3
Task 2 has finished.
Task 4 has finished.
Task 5 has finished.
Task 1 has finished.
Task 3 has finished.

Garbage Collection

Shreyans — Sat, 02 Sep 2023 20:28:42 +0000

Introduction

Programs run on data. Data lives in Memory. Memory needs management.

In simple words, Garbage Collection is an automated process which aids memory management by identifying and reclaiming memory occupied by objects that are no longer in use by a program, preventing memory leaks and ensuring efficient resource utilization.

A World Without GC

Not all programming language support GC. Without a Garbage Collector, the programmer is responsible for "freeing up" memory which is not being used anymore. This is known as Manual Memory Management.

If you are familiar with C/C++, you must have heard/read about malloc() and free() or new and delete. These are constructs which can be used by the programmer to manage the lifecycle of objects, from creation to deletion.

However, programmers are only human, and even with the best of intentions, manual memory management can often lead to serious issues. Two of the most common such issues are

Memory Leaks : This happens when you create an object on the heap but forget to delete it. Eventually, the heap gets filled with unused objects and any new request for allocating memory on the heap throws a Memory Limit Exceeded error.
Dangling Pointers : This happens when you delete an object prematurely even when some other pointers still reference it. Depending upon the programming language, this can manifest differently. Most severely, it can cause intermittent issues which may survive QA and pop up unexpectedly in Production.

That being said, while Manual Memory Management has its drawbacks, it may be desirable when you want to build applications with super critical memory/latency needs. In such use cases, using manual memory management, the developer can have maximum control over the lifecycle of objects, and can decide when to create/delete them so as to optimise memory/latency performance.

Popular GC Algorithms

Modern programming languages like Java and Python support Garbage Collection. Often, The Garbage Collector runs in separate thread(s) than the main program thread(s) (also called as mutator threads), and every time it executes, it works towards collecting the garbage. While the goal of Garbage Collectors remains the same, they can be implemented in many different ways. Two popular Garbage Collection algorithms are

Mark And Sweep (Java) : This is classic algorithm which is used by Garbage Collectors for reclaiming memory occupied by "unreachable" or "dead" objects in the heap. It works in 2 phases. In the "Mark" phase all "reachable" or "live" objects are marked by traversing the object reference graph starting from the known root references. In the "Sweep" phase the heap is traversed and all memory which is not marked is reclaimed for reuse.
Reference Counting (Python) : This is an algorithm which keeps track of the reference count of each object to track garbage. Every time a reference to an object is created, the reference count for that object is incremented. Similarly, every time a reference to an object is deleted or replaced, the reference count for that object is decremented. When the reference count of an object becomes 0, it is considered eligible for garbage collection.

Both of these have their pros and cons. For example

Mark and Sweep might cause "Heap Fragmentation" where the used heap memory becomes divided into small non-contiguous blocks. This makes it difficult to find space which may be needed for a Large contiguous data structure (like an Array). A variation of the Mark and Sweep, known as Mark, Sweep and Compact deals with Fragmentation.
Reference Counting cannot collect circular data structures (like circular linked lists) because each node has a reference count of 1 even after the original reference to the "head" has been removed. This inability of Reference Counting to collect circularly referenced structures can cause Memory Leaks. Due to this, Python versions 3.4 and above also include a cyclic garbage collector to handle circular references and objects that are not properly cleaned up by reference counting alone.

Java : Interpreted or Compiled ? JIT and AOT !

Shreyans — Sun, 27 Aug 2023 08:00:18 +0000

As a programmer, you may have read about the concept of interpreted languages or compiled languages.

Interpreted languages (example. BASIC) are those in which the source code is directly executed by the interpreter. Compiled languages (example. C++) on the other hand are those in which a compiler converts the source code into machine code before execution.

Is Java interpreted or compiled ? Traditionally speaking, the answer is that Java is both interpreted and compiled. But the more nuanced answer is that it depends on how you choose to execute your Java program.

The most popular (and maybe one could even say the "default") way of executing java programs is by using javac to covert the source code into bytecode and then executing the bytecode on a Java Virtual Machine (JVM).

While there are a number of JVMs to choose from, the most popular JVM on the planet is Oracle's HotSpot VM which was first introduced in 1999. If you have java installed on your machine, type java --version in the command line and inspect the output. You'll most likely see a reference to the HotSpot VM.

Therefore, generally speaking what one would do is

Use the Java Compiler (javac) which comes bundled in the Java Development Kit (JDK) to compile the source code (.java) and produce bytecode (.class) .
Invoke the jvm using the java command so that the JVM can interpret the bytecode and execute it line by line.
During interpretation, the JVM executes each line of bytecode by first converting it into the corresponding machine instruction.
Corresponding to that line of bytecode, JVM submits the machine instruction to the CPU for the CPU to execute it.

But that's not all. Even during interpretation, the HotSpot VM analyses the "hot" (very simply put this means frequently invoked) areas of your program and caches the compiled version of those areas so that it does not have to repeat step 3 again and again. This is popularly known as Just In Time Compilation (JIT). So now you can probably see that the execution of a Java program is not simply "interpretation" or "compilation", rather it is a well balanced combination of both in the pursuit of portability and performance.

This is why, generally speaking, Java is considered to be a both interpreted and compiled language.

But, there are some other ways of executing Java programs which may be better suited in certain use cases.

One of these is the very popular GraalVM project which offers an Ahead Of Time (AOT) compilation capability using its Native Image technology to directly compile Java source code into native machine code for execution.

Let's see how the "compilation" and "execution" phases differ in both cases in terms of time performance. While there are a lot of other aspects to be compared, the time based comparison will give you a basic idea as to why AOT may be better than JIT for some use cases.

We will use this program in both cases :

public class ComputeSquareRoots {
    public static void main(String[] args) {
        int numberOfRuns = 10000;
        long totalTime = 0;

        for (int i = 0; i < numberOfRuns; i++) {
            long startTime = System.nanoTime(); // Start time
            compute();
            long endTime = System.nanoTime(); // End time
            long executionTime = endTime - startTime;
            totalTime += executionTime;
        }

        double averageTime = (double) totalTime / numberOfRuns;

        System.out.println("Average Running Time: " + averageTime + " nanoseconds");
    }

    public static void compute() {
        for (int i = 0; i < 1_000_000; i++) {
            for (int j = 0; j < 100; j++) {
                Math.sqrt(i + j);
            }
        }
    }
}

Here is the command line output of each step.

As you can see

The compilation phase with javac took ~400ms to produce the bytecode.
The execution phase with JVM took ~40,000ns as reported by the output of our code.
The compilation phase for native-image was actually two step as it took the bytecode produced by javac as input. Therefore, total compilation time can be considered as ~400ms + ~16800ms which is ~17200ms. This is more than 40 times more as compared to JIT.
The execution phase for the AOT compiled native executable was ~30ns as reported by the output of our code. This is more than 1000 times less as compared to JIT.

So, while AOT has a longer compilation phase, it gives time advantage during the execution phase.

The example presented above is an over-simplified one to aid basic understanding. The choice between JIT and AOT in not as simple as this in most cases. There are a lot more aspects to consider. That being said, I hope this article helped you get a basic understanding of these concepts.