A journey to write efficient multithreaded code

This article is a part of a Well Synchronized, Yet Asynchronous series. Check out the previous article to join the journey!

Well Synchronized, Yet Asynchronous — Immutable Menu

Once customers check the Bigtaurant’s menu simultaneously, they are ready to place their orders. Bob’s implementation was inefficient, and customers were complaining about waiting too long. We can help Bob improve his application’s performance by using concurrent collections in Java.

Bob’s original implementation

Bob wanted to ensure that dishes were prepared and served in the same order that customers ordered them. To do this, he decided to use a Queue per dish to hold the order of customers who ordered the dish. He then used a Map to map each dish to its corresponding Queue.

Map<Dish, Queue<Integer>> orderMap = new HashMap<>();

When a customer orders a dish, their id is be inserted into the queue for that dish. This way, Bigtaurant knows which customer ordered the dish first and can serve the food when it’s ready.

Here’s the order method from Bob.

public synchronized void order(int customerId, Dish dish) {
    if (!orderMap.containsKey(dish)) {
        orderMap.put(dish, new LinkedList<>());
    }

    orderMap.get(dish).add(customerId);
}

To work with orderMap instance safely, Bob wrapped the method with synchronized keyword. This made the method thread-safe, but it also caused some inefficiency.

Issues

Just like the problem that the synchronized block caused when customers were reading the menu, the synchronized in order() method also forces customers to order sequentially. This means that one customer has to wait if there are other customers who are ready to order.

As you saw in the previous article, this will slow down the application and make customers complain about not taking their orders. Bob’s biggest mistake here is to use collections that are not designed for thread-safety. We can help Bob by replacing these into concurrent collections.

Concurrent Collections

Concurrent collections are a set of classes in the Java Collections Framework that provide thread-safe access to data structure. They are preferred over basic collections like Map or Queue because they make asynchronous programming much simpler by eliminating the need for explicit synchronization.

There are a number of concurrent collections that Java have.

• ConcurrentHashMap: A thread-safe implementation of the Map interface. It maintains the order of elements in insertion order.
• ConcurrentLinkedQueue: A thread-safe implementation of the Queue interface. It maintains the FIFO (first in, first out) order of elements.
• CopyOnWriteArrayList: A thread-safe implementation of the ArrayList interface. It creates a copy of the array when it is modified, which ensures that no threads are reading stale data.
• CopyOnWriteArraySet: A thread-safe implementation of the HashSet interface. It works similarly to CopyOnWriteArrayList, but it is used to store sets of elements.
• ConcurrentSkipListMap: A thread-safe implementation of the Map interface that is sorted by its keys. It is a good choice for applications that require concurrent access to a sorted map.
• ConcurrentSkipListSet: A thread-safe implementation of the Set interface that is sorted by its elements. It is a good choice for applications that require concurrent access to a sorted set.

The names of the collections are quite straight-forward and you can choose the concurrent collection that matches your needs. Here, we will use ConcurrentHashMap and ConcurrentLinkedQueue.

ConcurrentHashMap

ConcurrentHashMap is a concrete and concurrent hash table implementation of the Map interface. It is thread-safe and allows multiple threads to access and modify it.

From Bob’s implementation, we can replace HashMap with ConcurrentHashMap. We can also have the orderMap as ConcurrentMap to imply that it is thread-safe.

private static final ConcurrentMap<Dish, Queue<Integer>> orderMap
            = new ConcurrentHashMap<>();

Now that we have replaced HashMap with ConcurrentHashMap, the Map operations are thread-safe. We no longer have to make the whole order() method synchronized. However, the Queue is still not thread-safe. Let’s go fix that right now.

ConcurrentLinkedQueue

ConcurrentLinkedQueue is a thread-safe implementation of the Queue interface. ConcurrentLinkedQueue is a thread-safe implementation of the Queue interface. It maintains the FIFO order of elements. ConcurrentLinkedQueue can be a great option if you need a thread-safe queue.

In the order() method, we can replace the instantiation of LinkedList with ConcurrentLinkedQueue to ensure thread-safety.

public void order(int customerId, Dish dish) {
    if (!orderMap.containsKey(dish)) {
        orderMap.put(dish, new ConcurrentLinkedQueue<>());
    }

    orderMap.get(dish).add(customerId);
}

Conclusion

We now have a thread-safe order() method without a synchronized keyword. It is more efficient than the previous implementation and it was a simple change that had a huge impact.

Making your code thread-safe efficiently does not require extensive work. Instead. it involves a combination of small enhancements. See you on the next installment!

Check out my other stories!

The beginning of the Well Synchronized, Yet Asynchronous series:

Well Synchronized, Yet Asynchronous — Bigtaurant Opens!

Multithreading in Java:

5 Multithreading Options in Java

Code sharing with static vs Dpendency Injection

How Do I Provide My Method? With “static” or Through Dependency Injection?

A journey to write efficient multithreaded code

This article is a part of a Well Synchronized, Yet Asynchronous series. Check out the beginning of the journey below.

Well Synchronized, Yet Asynchronous — Bigtaurant Opens!

In this article, we will help Bob on showing the Bigtaurant’s menu to the customers. We will mainly focus on:

• Risks of sharing mutable instances
• Data class
• Record
• Immutable list

Bob’s original implementation

Bigtaurant serves various menus. Bob tried his best to let customers read the menu efficiently, but found a lot of issues.

Menu

Here’s the Dish class that Bob wrote.

package wsya.dish;

public class Dish {
    public String name;
    public int price;

    public Dish(String name, int price) {
        this.name = name;
        this.price = price;
    }

    @Override
    public String toString() {
        return "{" + name + " : " + price + "}";
    }
}

He then created an array to hold the menu they have.

private static final Menu[] menu = {
        new Menu("CheeseBurger", 9.0),
        new Menu("OnionBurger", 8.5),
        new Menu("CheesePizza", 18.0),
        new Menu("PepperoniPizza", 19.5),
        new Menu("Coca Cola", 2.5),
};

Customer

When customers enter, they check the menu. Bob smartly marked the class abstract and let the subclasses implement checkMenu() in their own way. Because the menus instance is shared, Bob wrapped the checkMenu() call with a synchronized block.

package wsya;

import wsya.menu.Dish;

public abstract class CustomerRunnable implements Runnable {
    private final Dish[] menu;

    public CustomerRunnable(Menu[] menu) {
        this.menu = menu;
    }

    @Override
    public void run() {
        synchronized (menu) {
            checkMenu(menu);
        }
    }

    protected abstract void checkMenu(Dish[] menu);
}

Bigtaurant is so loved that 10 people (which is so many that I can’t even imagine) were willing to enter. Bob created a thread pool with 5 threads using an ExecutorService to serve the customers.

// 5servers
ExecutorService executorService = Executors.newFixedThreadPool(5);

// Handle 10 customers
for (int i = 0; i < 10; i++) {
    executorService.submit(new CustomerRunnable(menus) {
        @Override
        protected void checkMenu(Menu[] menu) {
            // Do customized menu checking.
        }
    });
}

executorService.shutdown();

Issues

Bob put the customizable block in synchronized to prevent any troubles. What can possibly go wrong?

Only one customer can read the menu at a time

Because the checkMenu() is locked with menu instance, no two customers can read the menu at the same time. It takes some time for the customers to read the menu, say 1 second.

int customerId = i;
executorService.submit(new CustomerRunnable(menus) {
    @Override
    protected void checkMenu(Menu[] menu) {
        System.out.println("[" + new Timestamp(System.currentTimeMillis()) + "] " +
                "Customer " + customerId + " is reading menu.");
        System.out.println("\t" + Arrays.toString(menu));

        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }
});

When running the code, you can see that customers are reading the menu one next to one.

This makes multithreading useless. It’s just same as having everything synchronized. This can especially be problematic when one customer takes a long time reading a menu. The customer will block all other customers, lowering the efficiency in a huge rate.

Customers doodling

A few customers had a complaint about not finding the dish they want. They ended up with replacing them into their own.

System.out.println("[" + new Timestamp(System.currentTimeMillis()) + "] " +
        "Customer " + customerId + " is reading menu.");
System.out.println("\t" + Arrays.toString(menu));

if (customerId == 2) {
    menu[2] = new Menu("My Favorite Dish!", 100000);
} else if (customerId == 4) {
    menu[4].name = "I hate this!";
}

try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
    throw new RuntimeException(e);
}

Below is what the customers read.

[2023-07-27 23:14:25.914] Customer 0 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {Coca Cola : 2.5}]
[2023-07-27 23:14:26.946] Customer 4 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {Coca Cola : 2.5}]
[2023-07-27 23:14:27.951] Customer 3 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {I hate this! : 2.5}]
[2023-07-27 23:14:28.955] Customer 2 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {I hate this! : 2.5}]
[2023-07-27 23:14:29.96] Customer 1 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {My Favorite Dish! : 100000.0}, {PepperoniPizza : 19.5}, {I hate this! : 2.5}]
[2023-07-27 23:14:30.962] Customer 8 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {My Favorite Dish! : 100000.0}, {PepperoniPizza : 19.5}, {I hate this! : 2.5}]
[2023-07-27 23:14:31.973] Customer 7 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {My Favorite Dish! : 100000.0}, {PepperoniPizza : 19.5}, {I hate this! : 2.5}]
[2023-07-27 23:14:32.99] Customer 6 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {My Favorite Dish! : 100000.0}, {PepperoniPizza : 19.5}, {I hate this! : 2.5}]
[2023-07-27 23:14:33.999] Customer 5 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {My Favorite Dish! : 100000.0}, {PepperoniPizza : 19.5}, {I hate this! : 2.5}]
[2023-07-27 23:14:35.003] Customer 9 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {My Favorite Dish! : 100000.0}, {PepperoniPizza : 19.5}, {I hate this! : 2.5}]

Customers reading after customer 2 are seeing “My Favorite Dish!” instead of CheesePizza. Similarly, customers after customer 4 are seeing the menu with “I hate this!” instead of Coca Cola.

After seeing the modified menu, some might even order them and get rejected, which is an unpleasant experience.

Immutables!

What can we do to avoid this hazard? Menu is not a thing that can be changed. Once set, that’s done. Nobody can change the menu that’s already defined. If you want to change some ingredients or recipes, that’s a separate dish.

Immutable Class

To prevent overriding the fields’ values, which is what customer 4 did, we can make each menu immutable so that no customer codes can change the menu we provided. This can be done by marking the fields final.

public class Dish{
    public final String name;
    public final double price;

    public Dish(String name, double price) {
        this.name = name;
        this.price = price;
    }

    ...
}

Now customers will only be able to read the name and price. If the customer codes try to set the value to something else, they will face a compile error.

These immutable classes are often referred to as Data Classes, and many other languages support creating them at their language level. Java also provides record from Java 16.

record provides a functionality to define and initialize public final fields directly from the constructor and implements equals(), hashCode(), and toString() based on its fields.

Instead of making Dish a class and writing public finals with a constructor, you can rewrite it as follows.

public record Dish(String name, double price) {

    @Override
    public String toString() {
        return "{" + name + " : " + price + "}";
    }
}

The constructor and the fields definition became much more concise. Also, note that record implements toString(), so our toString() implementation is not really necessary to see the value of each field, but is only there to construct the String in the format of our preference.

Immutable List

One concern is still remaining. Customer codes can replace the menu itself into a totally different menu, just as what customer 2 did. Arrays are naturally mutable. To have immutability, we will use an immutable list.

The most simple and general way to create one is using List.of() method. This method takes multiple parameters and returns an immutable list that contains the given parameters as its elements.

The new menu with immutability is as follows:

private static final List<Menu> menu = List.of(
        new Dish("CheeseBurger", 9.0),
        new Dish("OnionBurger", 8.5),
        new Dish("CheesePizza", 18.0),
        new Dish("PepperoniPizza", 19.5),
        new Dish("Coca Cola", 2.5));

The menu list are now immutable, not able to add, delete, or replace.

Synchronization

Customer codes are no longer able to modify the menu. They will raise a compile error when they try to update a record, and will have no luck with changing the immutable list.

Immutables are free from synchronization as other threads are guaranteed to not change the values. This means, synchronized can be removed from the CustomerRunnable’s run() method. (Also note that the class now holds List<Dish> instead of Dish[].)

public abstract class CustomerRunnable implements Runnable {
    private final List<Dish> menu;

    public CustomerRunnable(List<Dish> menu) {
        this.menu = menu;
    }

    @Override
    public void run() {
        checkMenu(menu);
    }

    protected abstract void checkMenu(List<Dish> menu);
}

Running the code again, you’ll see that customers are reading the menu at the same time.

[2023-07-27 23:35:43.867] Customer 1 is reading menu.
[2023-07-27 23:35:43.867] Customer 0 is reading menu.
[2023-07-27 23:35:43.867] Customer 3 is reading menu.
[2023-07-27 23:35:43.867] Customer 2 is reading menu.
[2023-07-27 23:35:43.867] Customer 4 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {Coca Cola : 2.5}]
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {Coca Cola : 2.5}]
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {Coca Cola : 2.5}]
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {Coca Cola : 2.5}]
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {Coca Cola : 2.5}]
[2023-07-27 23:35:44.892] Customer 5 is reading menu.
[2023-07-27 23:35:44.892] Customer 6 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {Coca Cola : 2.5}]
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {Coca Cola : 2.5}]
[2023-07-27 23:35:44.893] Customer 7 is reading menu.
[2023-07-27 23:35:44.893] Customer 8 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {Coca Cola : 2.5}]
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {Coca Cola : 2.5}]
[2023-07-27 23:35:44.895] Customer 9 is reading menu.
 [{CheeseBurger : 9.0}, {OnionBurger : 8.5}, {CheesePizza : 18.0}, {PepperoniPizza : 19.5}, {Coca Cola : 2.5}]

Looking into the details, you’ll see that five customers start reading together. This is because we’re using a thread pool with five threads. Each thread takes a customer, and after one second, when the customers have finished reading the menu, the next set of customers can start reading.

Conclusion

Bob was incredibly happy to see the optimized result. Using immutables, you made 10 customers read the menu in two seconds, which previously took 10 seconds. This is a huge improvement!

There are a lot of more enhancements to be made to Bob’s other codes. The journey has just been started. Hold on tight!

A journey to write efficient multithreaded code

If you are new to multithreading, check out my previous article to grasp on how you can apply it to your application. It shows you ways to easily boost your application’s performance.

5 Multithreading Options in Java

Multithreading is a prominent aspect of modern applications. It helps the application leverage the full power of computing resources. However, excessive use of synchronized or other multithreading techniques can cause negative impacts, such as increased latency, deadlocks, etc.

This article is the beginning of a series, “Well Synchronized, Yet Asynchronous”. In this series, we will go through steps to build an efficient multithreaded application. Each article will cover one synchronization technique. Let’s begin the journey!

Bigtaurant Opens!

Bob is an owner of a big restaurant, Bigtaurant. With countless customers visiting everyday, Bob wants to build an application to manage the restaurant. There are so many things happening at the same time in Bigtaurant so Bob wants threads to play a role.

To avoid mess, Bob puts everything into synchronized blocks, making every part of the application Thread-Safe. This includes:

1. Showing Menu
2. Taking Orders
3. Cooking & Serving
4. Controlling Music
5. Handling Payments

The happiness of launching a new application didn’t last long. Bob finds that the application is lagging and only one of the many threads is running at a time, leaving other threads waiting for it to finish.

Bob’s mistakes

Bob put everything into synchronized blocks. The easiest way to make something thread-safe is indeed to mark the method synchronized and it’s easy to get lured or tempted. Too much use of synchronized when it’s not necessary, however, makes threads useless.

Consider the following code that Bob wrote.

public class BigtaurantApplication {
 public synchronized void order(int customerId, Dish dish) { ... }

 public synchronized void changeMusic(Music music) { ... }
}

synchronized methods are locked on the instance. In this case, the instance of BigtaurantApplication. This means that only one synchronized method can be called at the same time. You can see that it is quite inefficient. Making an order and changing the music have nothing to do with each other and don’t have to run one next to one. synchronized methods can lay this kind of inefficiency very easily and always be used with care.

Let’s say Bob somehow managed to separate them and made them run in parallel. Here is what Bob wrote for the order() method.

public void order(int customerId, Dish dish) {
  synchronized (orderMap) {
    Queue<Integer> customersWaitingForFood = orderMap.get(dish);
    customersWaitingForFood.add(customerId);
  }
}

Bob used Map and Queue to manage the customers who ordered each menu. It looks better than the previous code, as it can run at the same time with changeMusic, but it’s still not efficient enough.

Because it is locked on the orderMap instance, only one customer can order their food at once. If one customer is ordering food, all the customers ready to make an order should wait.

Bob desperately wants the application to be faster and needs a lot of help on synchronization. Throughout the next several articles, we will help Bob rebuild his application by covering the following synchronization techniques:

• Immutables

Well Synchronized, Yet Asynchronous — Immutable Menu

• Concurrent Collections
• Producer & Consumer pattern
• Lock
• Atomics

Once we finish the journey, you will be able to use each synchronization method in their appropriate situation. Bob will also love the outcome.

Stay tuned!

Computing power and performance have skyrocketed since their invention. The number of cores and their potentials are like nothing before, giving your application infinite possibilities. Despite the vast improvement, a single-threaded application can only utilize a maximum of one core and cannot benefit from the multi-cores that most modern computers have.

If you feel your application is lagging, compared to other applications in the world that do way more work, it being single-threaded might be the culprit. The solution: multithreading. If this is what you need, consider applying one of the following methods.

1. Thread
2. Parallel Streams
3. ExecutorService
4. ForkJoinPool
5. CompletableFuture

When used appropriately, it could shake up your world and launch your career. Let’s see how you can transform your application into an efficient multithreaded one.

1. Thread

The first option is to use the Thread class. This way, you can control threads directly from their creation to management. Here’s an example.

CustomTask counts from 0 to count - 1 every 50 milliseconds.

public class CustomTask implements Runnable {
    private final String name;
    private final int count;

    CustomTask(String name, int count) {
        this.name = name;
        this.count = count;
    }

    @Override
    public void run() {
        for (int i = 0; i < count; i++) {
            System.out.println(name + "-" + i + " from " +
                    Thread.currentThread().getName());
            try {
                Thread.sleep(50);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }
    }
}

a, b, and c are the three instances of this class.

Thread a = new Thread(new CustomTask("a", 5));
Thread b = new Thread(new CustomTask("b", 10));
Thread c = new Thread(new CustomTask("c", 5));

Notice that b is expected to count twice as much as others. You want to run b while a and c run sequentially.

You can implement this behavior very easily.

// a, b start running first.
a.start();
b.start();

// c starts after a is finished.
a.join();
c.start();

And here is the result.

a-0 from Thread-0
b-0 from Thread-1
b-1 from Thread-1
a-1 from Thread-0
b-2 from Thread-1
a-2 from Thread-0
b-3 from Thread-1
a-3 from Thread-0
b-4 from Thread-1
a-4 from Thread-0
b-5 from Thread-1
c-0 from Thread-2
b-6 from Thread-1
c-1 from Thread-2
b-7 from Thread-1
c-2 from Thread-2
b-8 from Thread-1
c-3 from Thread-2
b-9 from Thread-1
c-4 from Thread-2

a and b started running together, printing out in turns. c began producing after a is done. Also, all of them are running in different threads. By manually creating instances of Thread, you can have full control over them.

However, be mindful that low-level thread handling requires synchronization and resource-management too, which can be more error-prone and complex.

2. Parallel Streams

Parallel streams are effective when you have to apply identical, repetitive, and independent tasks to all the elements in a large collection.

For example, image resizing is a heavy task to run sequentially; it will take forever to finish when you have a number of them. In this case, you can resize them in parallel as follows.

private static List<BufferedImage> resizeAll(List<BufferedImage> sourceImages,
                                             int width, int height) {
    return sourceImages
            .parallelStream()
            .map(source -> resize(source, width, height))
            .toList();
}

This way, images will be resized simultaneously, saving you much precious time.

3. ExecutorService

You can consider using ExecutorService when the implementation doesn’t require precise thread controls. ExecutorService provides higher-level abstraction for thread management, including thread pooling, task scheduling, and resource management.

ExecutorService is an interface and its most general usage is the thread pool. Suppose that you have piles of asynchronous tasks stacking up, but running them all at the same time — each of them taking up one thread — just seems too much. Thread pools can help you by limiting the maximum number of threads to use.

Below, we’re using ExecutorService instantiated by Executors.newFixedThreadPool() to run 10 tasks with 3 threads. Each task will only print a single line. Note that we’re reusing the CustomTask defined in the previous section.

ExecutorService executorService = Executors.newFixedThreadPool(3);

for (int i = 0; i < 10; i++) {
    executorService.submit(new CustomTask(String.valueOf(i), 1));
}

executorService.shutdown();

This prints out the following.

0-0 from pool-1-thread-1
2-0 from pool-1-thread-3
1-0 from pool-1-thread-2
4-0 from pool-1-thread-3
3-0 from pool-1-thread-2
5-0 from pool-1-thread-1
6-0 from pool-1-thread-1
7-0 from pool-1-thread-3
8-0 from pool-1-thread-2
9-0 from pool-1-thread-3

10 tasks are running in 3 threads. By limiting the number of threads used for specific tasks, you can assign the number of threads depending on the priorities: more threads for important and frequent tasks, and less threads for trivial or occasional tasks. With high efficiency and simplicity, ExecutorService is a preferred option for most multithreading scenarios.

If you feel the need for more control and flexibility, check out ThreadPoolExecutor, which is an actual implementation of ExecutorService that Executors.newFixedThreadPool() returns. You can directly create its instance or cast the returned ExecutorService instance to gain more control.

4. ForkJoinPool

ForkJoinPool is another type of thread pool, as its name implies. While it is used under the hood of a lot of other asynchronization methods, it is also very powerful for tasks that can be divided into smaller, and independent sub-tasks, which can be solved by divide-and-conquer strategy.

One such task is image resizing. Image resizing is a great example of a divide-and-conquer problem. With ForkJoinPool, you can divide the image into two, or four smaller images and resize them in parallel. The following demonstrates ImageResizeAction, which resizes the image into a given size.

package multithreading;

import java.awt.image.BufferedImage;
import java.util.concurrent.RecursiveAction;

public class ImageResizeAction extends RecursiveAction {
    private static final int THRESHOLD = 100;

    private final BufferedImage sourceImage;
    private final BufferedImage targetImage;
    private final int startRow;
    private final int endRow;
    private final int targetWidth;
    private final int targetHeight;

    public ImageResizeAction(BufferedImage sourceImage,
                             BufferedImage targetImage,
                             int startRow, int endRow,
                             int targetWidth, int targetHeight) {
        this.sourceImage = sourceImage;
        this.targetImage = targetImage;
        this.startRow = startRow;
        this.endRow = endRow;
        this.targetWidth = targetWidth;
        this.targetHeight = targetHeight;
    }

    @Override
    protected void compute() {
        if (endRow - startRow <= THRESHOLD) {
            resizeImage();
        } else {
            int midRow = startRow + (endRow - startRow) / 2;
            invokeAll(
                    new ImageResizeAction(sourceImage, targetImage,
                            startRow, midRow, targetWidth, targetHeight),
                    new ImageResizeAction(sourceImage, targetImage,
                            midRow, endRow, targetWidth, targetHeight)
            );
        }
    }

    private void resizeImage() {
        int sourceWidth = sourceImage.getWidth();
        double xScale = (double) targetWidth / sourceWidth;
        double yScale = (double) targetHeight / sourceImage.getHeight();

        for (int y = startRow; y < endRow; y++) {
            for (int x = 0; x < sourceWidth; x++) {
                int targetX = (int) (x * xScale);
                int targetY = (int) (y * yScale);
                int rgb = sourceImage.getRGB(x, y);
                targetImage.setRGB(targetX, targetY, rgb);
            }
        }
    }
}

Note that ImageResizeAction inherits RecursiveAction. RecursiveAction is used to define the recursive resizing action. In this example, the image is divided into half and resized concurrently.

You can run the ImageResizeAction with the following code:

public static void main(String[] args) throws IOException {
    String sourceImagePath = "source_image.jpg";
    String targetImagePath = "target_image.png";
    int targetWidth = 300;
    int targetHeight = 100;

    BufferedImage sourceImage = ImageIO.read(new File(sourceImagePath));
    BufferedImage targetImage = new BufferedImage(targetWidth, targetHeight,
            BufferedImage.TYPE_INT_RGB);

    ForkJoinPool forkJoinPool = new ForkJoinPool();
    forkJoinPool.invoke(new ImageResizeAction(sourceImage, targetImage,
            0, sourceImage.getHeight(), targetWidth, targetHeight));

    ImageIO.write(targetImage, "png", new File(targetImagePath));

    System.out.println("Image resized successfully!");
}

With the help of ForkJoinPool, you are now able to resize an image more efficiently, with more scalability, and with maximized resource usage.

5. CompletableFuture

With CompletableFuture, you can have full functionality of Future and a number of additional features. The most prominent feature of it is its ability to chain asynchronous operations, allowing you to build complex asynchronous pipelines.

public static void main(String[] args) {
    CompletableFuture<Void> future = CompletableFuture.supplyAsync(() -> {
        System.out.println(Thread.currentThread().getName());
        return "Hyuni Kim";
    }).thenApply((data) -> {
        System.out.println(Thread.currentThread().getName());
        return "My name is " + data;
    }).thenAccept((data) -> {
        System.out.println(Thread.currentThread().getName());
        System.out.println("Result: " + data);
    });

    future.join();
}

The above code shows a key aspect of the CompletableFuture: chaining. With CompletableFuture.supplyAsync(), first CompletableFuture that results in a string is created and run. thenApply() accepts the result from the previous task and performs additional stuff, in this case, appending a string. Lastly, thenAccept() prints out the generated data. The result is as follows.

ForkJoinPool.commonPool-worker-1
ForkJoinPool.commonPool-worker-1
ForkJoinPool.commonPool-worker-1
Result: My name is Hyuni Kim

3 tasks were not run in the main thread, indicating that they were run in parallel with the main logic. When you have tasks that have results and should be chained, CompletableFuture will be a great option.

Summary

The absence of multithreading is like using only one pizza machine in a pizza store. It is inefficient and users will complain about it. Applying mutithreading is not difficult at all. With a simple change, you’ll be able to leverage the full power of computers today. Try multithreading now to unleash the new efficiency level of your application!

When you write Java code, you don’t just put all the codes in a single file or class. Not only does it hurt readability, but it also lacks modularity and maintainability, making the code less scalable. Instead, we separate the codes into multiple files and classes, and reuse the behaviors defined in an appropriate class.

Now, how about the features that are widely used and are not instance-specific? Say, checking whether the user is over 18, or converting the date into a string. We then face the dilemma: do we use static class or dependency injection? In this article, we go through the pros and cons, use cases, complexity, testing, and performance of them and give you a quick guide on which one to use. Let’s begin by looking into static classes and dependency injection in detail.

Static class

Static classes in Java are used to hold static members and can be accessed without any instantiation. Because of this, static classes usually group methods that perform generic tasks and don’t make use of any specific instance data.

Examples

Here’s an example. ConversionUtil class is a static class that provides static methods to convert different units.

public class ConversionUtil {
    public static double cmToFeet(double cm) {
        return cm / 2.54 / 12;
    }
    
    public static double feetToCm(double feet) {
        return feet * 2.54 * 12;
    }
}

Static classes can also hold constants, defined with static final keyword. Math class, a well-known static class built within Java, defines the constants this way.

public final class Math {
    ...

    /**
     * The {@code double} value that is closer than any other to
     * <i>e</i>, the base of the natural logarithms.
     */
    public static final double E = 2.7182818284590452354;
    /**
     * The {@code double} value that is closer than any other to
     * <i>pi</i>, the ratio of the circumference of a circle to its
     * diameter.
     */
    public static final double PI = 3.14159265358979323846;
    /**
     * Constant by which to multiply an angular value in degrees to obtain a
     * angular value in radians.
     */
    private static final double DEGREES_TO_RADIANS = 0.017453292519943295;
    /**
     * Constant by which to multiply an angular value in radians to obtain a
     * angular value in degrees.
     */
    private static final double RADIANS_TO_DEGREES = 57.29577951308232;
    
    ...

Pros & Cons

Static classes are easy to write and access. We only have to write a class with static fields and any other classes can directly access them. Easy-to-write is a huge benefit for projects that need high velocity as it can make programmers focus on the business logic of an application.

However, static classes may introduce tight coupling, meaning that their use can create strong dependencies and interconnections between different components of an application. They can lead their dependencies to be tightly coupled to their specific implementation details because they are used without any object instantiation.

This also reduces testability. It’s not easy to stub or mock static methods with testing libraries like JUnit or Mockito. When writing code for the dependency that references the static members, you’ll have to write test codes that also test their behavior, which is not a desirable practice.

Dependency Injection

Dependency Injection (DI) is a design pattern that is widely used in Java development. It provides decoupling of the creation and management of dependencies, resulting in loose coupling and modular design.

The key concept of DI is the Inversion of Control (IoC). With DI, we don’t control the instance, specifically, object creation and dependency resolution. Instead, instances are provided to the dependents, typically through a constructor or setter.

Examples

Spring is one of the well-known frameworks with DI. In Spring, numerous classes are under DI’s management. For example, to handle a task around the User, you’ll write a UserService class and get it injected into your controller as follows:

@RestController
public class UserController {
    private final UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }

    ...
}

Pros & Cons

With dependency injection, you don’t have to worry about creating and managing the instances. This allows dependents to depend on the interfaces rather than the concrete implementation, resulting in loose coupling. The dependents don’t need to know the implementation details and only consider what behavior they are calling results in.

DI is also strong at writing tests. Because of the loose coupling and the dependents not having to rely on the implementation of the dependencies, both dependents and dependencies can be tested independently.

The downside of the DI is, of course, the learning curve and the complexity of the application. DIs may not be very intuitive at first glance. You might not catch what creates the instances and how they wire into your class. However, DIs are not that complex and you will find yourself creating and injecting your instances in no time.

What to use?

We have gone through the meanings, and pros & cons of both static classes and DI. So which one should we use?

Static classes are simple and easy while DIs are modular and scalable. So if your application is in its inception, you might want to write with static classes as they don’t require additional configuration and can be written fast.

If your project is on track, you can consider the role of the class. If the class is just providing a few simple methods that don’t have to be explicitly tested, such as pow(), convertCmToFeet(), or replaceAll(), it will be fine to write it as a static class. In most cases, static classes will hold utility functions or global states.

In contrast, if the functionality that the class is providing is complex and should be tested, such as UserService that manages the methods and behaviors related to the Users, you might want to write it in a common class and inject it.

Summary

So we discussed static classes and DIs. Choosing which one to use is obviously up to you and your team members. However, it is important to make decisions with reasons. I hope this article helped you in finding rationales on which one to use. Thanks for reading!

The release of Java 8 was a momentous occasion in Java’s history. Streams and Lambdas were introduced, and they’re now being used widely. If you don’t know about Streams or have never heard of it, it’s completely fine. In most cases, loops will meet your needs, and you’ll have no trouble without Streams.

Then why do we need Streams? Can they replace or have benefits over loops? In this article, we will look into the code, compare performance, and see how well Streams do as a replacement for loops.

Code Comparison

Streams increase code complexity as they need classes, interfaces, and imports; loops are, in contrast, built-in by nature. This is true in some points, but not necessarily. Code complexity is a lot more than how many things you need to know. It’s more about how readable the code is. Let’s look at some examples.

List of item names with a type

Let’s say that we have a list of items and want the list of names of specific item types. Using loops, you will write the following:

List<String> getItemNamesOfType(List<Item> items, Item.Type type) {
    List<String> itemNames = new ArrayList<>();
    for (Item item : items) {
        if (item.type() == type) {
            itemNames.add(item.name());
        }
    }
    return itemNames;
}

Reading the code, you’ll see that a new ArrayList should be instantiated, and type check and add() call should be made in every loop. On the other hand, here’s the stream version of the same result:

List<String> getItemNamesOfTypeStream(List<Item> items, Item.Type type) {
    return items.stream()
            .filter(item -> item.type() == type)
            .map(item -> item.name())
            .toList();
}

With the help of Lambda, you can immediately catch that we’re first choosing the items with the given type, then getting the list of names of the filtered items. In this kind of code, the line-by-line flow aligns well with the logical flow.

Generate a random list

Let’s look at another example. In the Time Comparison section, we’ll review key Streams methods and compare their execution time with loops. For this, we need a random list of Items. Here is a snippet with a static method that gives a random Item:

public record Item(Type type, String name) {
    public enum Type {
        WEAPON, ARMOR, HELMET, GLOVES, BOOTS,
    }

    private static final Random random = new Random();
    private static final String[] NAMES = {
            "beginner",
            "knight",
            "king",
            "dragon",
    };

    public static Item random() {
        return new Item(
                Type.values()[random.nextInt(Type.values().length)],
                NAMES[random.nextInt(NAMES.length)]);
    }
}

Now, let’s make a list of random Items using loops. The code will look like this:

List<Item> items = new ArrayList<>(100);
for (int i = 0; i < 100; i++) {
    items.add(Item.random());
}

The code with Streams looks like this:

List<Item> items = Stream.generate(Item::random).limit(length).toList();

A wonderful and easy-to-read code. Furthermore, the List returned by toList() method is unmodifiable, giving you immutability so you can share it anywhere in the code without worrying about side effects. This makes the code less error-prone, and the readers understand your code more easily.

Streams provide a variety of helpful methods that let you write concise codes. The most popular ones are:

• allMatch()
• anyMatch()
• count()
• filter()
• findFirst()
• forEach()
• map()
• reduce()
• sorted()
• limit()
• And more in Stream Javadoc

Performance

Streams behave like loops in normal circumstances and have little or no effect on execution time. Let’s compare some major behaviors in Streams with loop implementations.

Iterate elements

When you have a collection of elements, there are a plethora of cases where you iterate all the elements inside the collection. In Streams, methods like forEach(), map(), reduce(), and filter() do this kind of whole-element iteration.

Let’s think of a case where we want to count each type of item inside a list. The code with the for loop will look like this:

public Map<Item.Type, Integer> loop(List<Item> items) {
    Map<Item.Type, Integer> map = new HashMap<>();
    for (Item item : items) {
        map.compute(item.type(), (key, value) -> {
            if (value == null) return 1;
            return value + 1;
        });
    }
    return map;
}

The code with Streams looks like this:

public Map<Item.Type, Integer> stream(List<Item> items) {
    return items.stream().collect(Collectors.toMap(
            Item::type,
            value -> 1,
            Integer::sum));
}

They look quite different, but how will they perform? Below is the table of average execution times of 100 tries:

As we can see in the above comparison table, Streams and loops show little execution time difference in iterating the whole list. This is the same for other Stream methods like map(), forEach(), reduce(), etc., in most cases.

Optimization with parallel stream

So, we found that Streams don’t perform better or worse than loops when iterating the list. However, there is an amazing thing about Streams that loops do not have: we can easily perform multi-thread computing with streams. All you have to do is to use parallelStream() instead of stream().

To see how much impact we can gain from this, let’s look at the following example where we mock the long-taking task as follows:

private void longTask() {
    // Mock long task.
    try {
        Thread.sleep(1);
    } catch (InterruptedException e) {
        throw new RuntimeException(e);
    }
}

Looping through the list will look like this:

protected void loop(List<Item> items) {
    for (Item item : items) {
        longTask();
    }
}

Streams will look like this:

protected void stream(List<Item> items) {
    items.stream().forEach(item -> longTask());
}

And finally, parallel streams will look like this:

protected void parallel(List<Item> items) {
    items.parallelStream().forEach(item -> longTask());
}

Notice that only stream() has changed to parallelStream().

Here is the comparison:

As expected, loops and Streams show little difference. Then what about parallel streams? Sensational! It’s saving more than 80% of the execution time compared to other implementations! How is this possible?

Regarding tasks that take a long time to finish and should be done for each element in the list independently, they can run simultaneously, and we can expect significant improvement. This is what parallel streams are doing. They distribute them into multiple threads and make them run simultaneously.

Parallel streams are only sometimes a winner that you can use everywhere instead of loops or Streams. It is only useful when the tasks are independent. If the tasks are not independent and have to share the same resources, you’ll have to keep them safe with a lock, mainly by synchronized keyword in Java, and make them run slower than normal iterations.

Limitations

Streams, however, also have limitations. One case is conditional loops, and another one is repetitions. Let’s see what they mean.

Conditional loops

When we want to repeat until the condition is true but are not sure how many iterations it will take, we normally use the while loop.

boolean condition = true;
while (condition) {
    ...
    condition = doSomething();
}

The code that behaves the same using Streams looks like this:

Stream.iterate(true, condition -> condition, condition -> doSomething())
        .forEach(unused -> ...);

You can see that some boilerplate parts bother the reading, such as condition -> condition that checks whether the condition is true, and unused parameter inside the forEach(). Considering this, conditional loops are better written in while loops.

Repetition

Repetition is one of the main reasons for the for loop’s existence. Let’s say we want to repeat the process ten times. With the for loop, it can be easily written as:

for (int i = 0; i < 10; i++) {
  ...
}

In Streams, one way to achieve this is to make an IntStream that contains [0, 1, 2, ... , 9] and iterate it.

IntStream.range(0, 10).forEach(i -> ...);

Although the code may look concise and proper, it looks more focused on the values of the range 0 to 10 (exclusive), where the for loop code can be read repeat ten times as it’s more general to write repeat in this way: starting from 0 and ending having the number of repetition times.

Summary

We’ve gone through some comparisons between Streams and loops. So… can Streams replace loops? Well, as always, it depends on the situation! However, Streams can usually provide you with more concise, easy-to-read code and optimizations.

So, what are you waiting for? Go ahead and start writing your codes with Streams!

The codes written for this article can be found on my GitHub.

Can Streams Replace Loops in Java? was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.