DEV Community: A N M Bazlur Rahman

Book Review: Monolith to Microservices (Part 1)

A N M Bazlur Rahman — Mon, 25 Oct 2021 04:12:00 +0000

I have just finished reading “Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith” by Sam Newman.

This book is undoubtedly great; it explained a few critical aspects while moving away from a monolith to a Microservices architecture. In this article, I will try to summarize some of the elements from the book that impacted me.

This book contains five chapters, and each of them has a great deal of context and explanation. So I will go one by one.

Chapter # 1

This chapter starts with defining the concept, Microservices itself, the benefit and the problem it creates. So from the definition, Microservices will have the following key components-

A service that can be deployed independently. The idea is, a service has to have the ability to deploy in production without disrupting any other associated services. Therefore, any changes in a particular service shouldn’t affect any other service, which is essential for having Microservices.
A service has to be modelled around a business domain. The idea is, if you need to touch two or more services to deliver a feature, then that’s not an ideal scenario for Microservices. So we have to find a way so that his cross-service changes are less frequent.
Each service has to own its data. Again, we can compare this with the object-oriented design principle; the way a class encapsulates its fields, a service must encapsulate the data.

Now the question is, what are the benefits it brings to the table? Well many. It puts many options on the table; you can mix and match different technology. It offers us to choose mixing different programming languages, programming styles, deployment platforms or databases to find the right mix. Multiple services can be developed independently without getting each other ways. The developers can focus on their particular thing. Above all, it gives us flexibility. It opens up many more options regarding how we can solve a specific problem in future. Finally, it reduces the blast radius. If a particular service goes out of service, ideally, it shouldn’t impact any other services.

However, Microservice architecture does not give you a silver bullet; it also brings a lot of baggage. Communication between services becomes a bottleneck. We now have to worry about latencies, and they vary, and thus the system becomes unpredictable. The transactional behaviour that we cherish so much will go away out of the window. Network calls can and become a headache, for example, Service A is talking to Service B, but Service B might go offline. Since data are not in one place, getting a consistent view of data across multiple machines becomes difficult. In fact, microservice can be a terrible idea, except for all the good stuff it provides.

Putting all these pros and cons upfront, the book argues whether we really need to go forward with Microservices. Perhaps not, in many cases. There are still many benefits of having a monolith. For example, it has a much simpler deployment topology, much simpler developer workflow. Activities like monitoring, troubleshooting, end-to-end testing are relatively easy in the monolith. Besides, if you want to reuse code, it’s just there, and a method calls away.

Still, suppose you want to go for it. In that case, you must have a perfect reason for that: independent deployability, independent scalability, mix and max technology, reducing the blast radius, etc. Of course, it won’t be cheap, somewhat costly, but with Microservices, you can buy more options. Well, you certainly need to know that there is a cost associated with the term buying.

That’s for today; I will discuss the next chapter in the forthcoming article.

Java Thread Programming (Part 3)

A N M Bazlur Rahman — Thu, 21 Oct 2021 10:42:00 +0000

This article was first published in Foojay.io

Continuing from part 2, let’s start this article with a bit of context first (and if you don’t like reading text, you can skip this introduction, and go directly to the section below where I discuss pieces of code).

Context

When we start an application program, the operating system creates a process.
Each process has a unique id (we call it PID) and a memory boundary.
A process allocates its required memory from the main memory, and it manipulates data within a boundary.
No other process can access the allocated memory that is already acquired by a process.
It works like a sandbox, and in that way avoids processes stepping on one another’s foot.
Ideally, we can have many small processes to run multiple things simultaneously on our computers and let the operating systems scheduler schedule them as it sees fit.
In fact, this is how it was done before the development of threads. However, when we want to do large pieces of work, breaking them into smaller pieces, we need to accumulate them once they are finished.
And not all tiny pieces can be independent, some of them must rely on each other, and thus we need to share information amongst them.
To do that, we use inter-process communication. The problem with this idea is that having too many processes on a computer and then communicating with each other isn’t cheap. And precisely that is where the notion of threads comes into the picture.

The idea of the thread is that a process can have many tiny processes within itself. These small processes can share the memory space that a process acquires. These little processes are called a thread. So the bottom line is, threads are independent execution environments in the CPU and share the same memory space. That allows them faster memory access and better performance.

That seems to be a good idea. However, it comes with many problems alongside its benefits. Let’s discuss some of those problems and how we can deal with them. But don’t get discouraged, the benefits still outweigh the problems!

Code

Let’s begin by running a piece of code.

package com.bazlur.threads;

public class FoojayPlayground {
 private static boolean running = false;

 public static void main(String[] args) {
  var t1 = new Thread(() -> {
   while (!running) {
   }
   System.out.println("Foojay.io");
  });

  var t2 = new Thread(() -> {
   running = true;
   System.out.println("I love ");
  });

  t1.start();
  t2.start();
 }
}

The above piece of code is reasonably straightforward. We have created two threads. Both of them share a variable named “running”. There is a while loop inside the first thread. The loop will keep running while the variable is false, which means this thread will continue to execute the loop unless the variable is changed. Once the loop breaks, it prints “Foojay.io.” The second thread changes the variable and then prints “I love.”

Now the question gets to be, what would be the output?

Outwardly it seems the output would be following:

I love 
Foojay.io

Well, that’s only one case because if you run the above code several times, you will see different results. There would be three outcomes of the program, varying on different computers. The reason is, we can only ask the thread to execute a piece of code, but we cannot guarantee the execution order of multiple threads. Threads are scheduled by the operating system’s thread scheduler. We will discuss the thread’s lifecycle in forthcoming articles.

Case 1. The first thread will continue running the loop. In contrast, the second thread will change the variable and immediately print “I love”. Since the variable now changed, the loop breaks, and it prints “Foojay.io”, so that the output is:

I love 
Foojay.io

Case 2. The second thread will run first and change the variable and then immediately in the first thread, the loop will break and print the “Foojay.io”. And the second thread will print “I love”. Thus the output is:

Foojay.io 
I love

Case 3. The above two cases seem reasonable. However, there is a third case that we may not anticipate immediately: the first thread may be stuck and the second thread will print “I love” and that’s all. No more output. This can be difficult to reproduce, but it can happen.

Let me explain the third case!

We know the modern computer has multiple CPUs in it. Nonetheless, we cannot guarantee in which core the thread will eventually run. For example, the above two threads can run in two different CPUs, which most likely the case.

When a CPU executes a code, it reads data from the main memory. However, modern CPUs have various caches for faster access to memory. There are three types of cache associated with each CPU. They are L1 Cache, L2 Cache, and L3 Cache.

When starting the first thread, the CPU it runs may cache the running variable and keeps it running. But, on the other hand, when the second thread runs and changes the variable on a different CPU, it won’t be visible to the first thread. Thus the problem of the third case would occur.

We cannot tell whether this would be the case because it all depends on the operating system and having multiple CPUs in a computer. Despite this, we can prevent the CPU from caching, by using “volatile” in the variable. This will instruct the CPU not to cache the variable and, instead, it will read it from the main memory:

public class FoojayPlayground {
   private static volatile boolean running = false;
   ...
   ...
}

Now, if we run the above program, the third case will not happen.

The above problem is called the visibility problem. There are a few similar problems that deal with the visibility issue.

We will discuss them in the following articles!

That’s it for today!

Don’t Forget to Share This Post!

Java Thread Programming (Part 2)

A N M Bazlur Rahman — Tue, 12 Oct 2021 10:42:00 +0000

This article was first published in Foojay.io

In our earlier article, we explained the background to threading and how to create and start a thread.

In this article, let’s see an example where we can use Threads to our benefit.

Let’s assume we are going to build a web server. For the sake of the example, let’s constrain ourselves to one single use case, which is that the web server will listen to any client, and if it receives a URL, it will return the top five most frequently used words in that website.

OK, enough talk, let’s see the code!

package com.bazlur;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.MalformedURLException;
import java.net.ServerSocket;
import java.net.Socket;
import java.net.URL;
import java.util.stream.Collectors;

public class SingleThreadedServer {
  private final MostFrequentWordService mostFrequentWordService = new MostFrequentWordService();

  public SingleThreadedServer(int port) throws IOException {
    var serverSocket = new ServerSocket(port);
    while (true) {
      var socket = serverSocket.accept();
      handle(socket);
    }
  }

  private void handle(Socket socket) {
    System.out.println("Client connected: " + socket);

    try (var in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
         var out = new PrintWriter(socket.getOutputStream(), true)) {
      String line;

      while ((line = in.readLine()) != null) {
        if (isValid(line)) {
          var wordCount = mostFrequentWordService.mostFrequentWord(line)
                  .stream()
                  .map(counter -> counter.word() + ": " + counter.count())
                  .collect(Collectors.joining("\n"));
          out.println(wordCount);
        } else if (line.contains("quit")) {
          out.println("Goodbye!");
          socket.close();
        } else {
          out.println("Malformed URL");
        }
      }
    } catch (IOException e) {
      System.out.println("Was unable to establish or communicate with client socket:" + e.getMessage());
    }
  }

  private static boolean isValid(String stringURL) {
    try {
      new URL(stringURL);
    } catch (MalformedURLException e) {
      System.out.println("invalid url: " + stringURL);
      return false;
    }
    return true;
  }

  public static void main(String[] args) throws IOException {
    new SingleThreadedServer(2222);
  }
}

Let’s walk through the code first. In the above code, a ServerSocket starts at a port and waits in a loop for the clients to connect. The handle() method is the most important one. It gets a Socket object and then talks to the client. If a client sends a valid URL, It calls a service, MostFrequentWordService, to get the most frequent words.

We can use telnet to connect the server and use this server.

The only problem with this is it can handle only one client at a time. So if we try to connect another client, it will respond only when the other connected client gets disconnected.

That’s certainly a problem for a web server. A web server is supposed to connect with hundreds or thousands of clients simultaneously.

We can solve this problem quite quickly, if we turn this single-threaded program into a multi-threaded program. Recall the handle() method from the above code. Whenever a client connects, I can spawn a new thread and hand over the handle() method to that Thread:

Yes, that’s the trick. Let’s do it:

public class MultiThreadedServer {
  private final MostFrequentWordService mostFrequentWordService = new MostFrequentWordService();

  public MultiThreadedServer(int port) throws IOException {
    var serverSocket = new ServerSocket(port);
    while (true) {
      var socket = serverSocket.accept();

      var thread = new Thread(() -> handle(socket));
      thread.start();
    }
  }

  //rest of the code. 
}

Now, we can connect multiple clients at once, and serve them all simultaneously:

Now that we understand the benefits of using threads in Java, we will dig a bit deeper into using threads in the following articles in this series.

And in case you are interested in how I wrote the “MostFrequentWordService”, here it is:

package com.bazlur;

import org.jsoup.Jsoup;

import java.io.IOException;
import java.util.Arrays;
import java.util.Comparator;
import java.util.List;
import java.util.Map;
import java.util.function.Function;
import java.util.stream.Collectors;

record WordCount(String word, long count) {
}

public class MostFrequentWordService {
  public List mostFrequentWord(String url) throws IOException {
    var wordCount = Arrays.stream(getWords(url))
            .filter(value -> !value.isEmpty())
            .filter(value -> value.length() > 3)
            .map(String::toLowerCase)
            .collect(Collectors.groupingBy(Function.identity(), Collectors.counting()));

    return wordCount.entrySet()
            .stream()
            .sorted(Map.Entry.comparingByValue(Comparator.reverseOrder()))
            .limit(5)
            .map(entry -> new WordCount(entry.getKey(), entry.getValue()))
            .collect(Collectors.toList());
  }

  private String[] getWords(String url) throws IOException {
    var connect = Jsoup.connect(url);
    var document = connect.get();
    var content = document.body().text();

    return content.split("[^a-zA-Z]");
  }
}

That’s it for today!

Don’t Forget to Share This Post!

Java Thread Programming (Part 1)

A N M Bazlur Rahman — Thu, 07 Oct 2021 10:42:00 +0000

This article was first published in Foojay.io

What is a Thread?

We write code in a file line by line, and then it gets executed. To be able to execute a piece of code requires an execution environment. In Java, a thread is an execution environment. If a program has only one execution environment, then we call this program a single-threaded program.

Interestingly, in Java, we can create a lot of threads to run different parts of the code of a program executing independently. And when we have achieved that, we call it a multi-threaded program.

In short, a thread executes a piece of code on a computer.

What are some benefits of multiple threads?

The benefits of having multiple threads are enormous. Think about a web application that serves hundreds of users at a time, then the question would be, how it does it do that? Well, the answer is simple: it usually runs different requests on a separate thread. So each user gets a thread to execute their request.

Similarly, when I’m typing on this computer on a word processor, it’s doing multiple things simultaneously. One is perhaps checking my spelling, and one is possibly taking input from when I type on the keyboard. That way, we can achieve various tasks simultaneously. Otherwise, if the word processor would be a single-threaded program, it would need to first read input from the keyboard, and then only it would check the spelling. Naturally, then, the experience wouldn’t be pleasant, at all.

Why do we need to learn about threads?

We could think of many more similar examples in addition to the one mentioned above, but let’s think about the current computer architecture. The modern computer comes with multiple cores, since clock speed isn’t increasing anymore nowadays. The laptop I’m using at this moment has 16 cores. That means that at a point in time, it can run 16 different things. If a program is single-threaded, then it can only utilize 1 core at the moment, the rest of the 15 would be just idle. We shouldn’t waste valuable resources like this.

So, we should be able to write our program in a way to utilize the available resources in the best possible way. On the other hand, if an application can do multiple things at once, we can achieve substantial progress quickly, and the application can become more responsive. We can even subdivide a program into various independent units and then execute them in parallel, resulting in faster results.

Do all Java programs have a thread associated with them?

The answer is yes. Java was designed to have threads from the very beginning. If we just start a “hello world” program in the main method, it will be executed through a thread, which is called the “main Thread”. Let’s see an example:

package com.bazlur;

public class HelloWorld {
 public static void main(String[] args) {
  System.out.println("This program is running on: " + Thread.currentThread());
  System.out.println("Hello world");
 }
}

Note: Thread.currrentThread() method returns the reference of the Thread currently executing the piece of code.

If we run the above program, then we will get the following output in the console:

This program is running on: Thread[main,5,main]
Hello world

So, the output ensures us that running a Java program is all about running its different pieces of code on one or multiple threads.

How do I create my own threads?

The code that writes in the main method executes by means of the main Thread. However, we can have more threads to run multiple pieces of code at once. There are two ways of creating threads:

Through extending the java.lang.Thread class
Through an interface called java.lang.Runnable

Let’s start by extending the Thread class.

package com.bazlur;

public class MyThread extends Thread {
 @Override
 public void run() {
  System.out.println("Executing code from: " + Thread.currentThread());
  System.out.println("Hello world");
 }
}

In the above code, we have created a class, MyThread, extending the Thread class, and then we override the run method. Thus, whatever we write in this run method will be executed by this Thread.

To use this Thread, we have to create an instance and then call its start() method:

package com.bazlur;

public class Playground {
 public static void main(String[] args) {
  System.out.println("Creating a new thread from : " + Thread.currentThread());
  var myThread = new MyThread();
  myThread.start();
  System.out.println("Leaving from: " + Thread.currentThread());
 }
}

In the above code, the main method gets executed by the main Thread. The main Thread sees the code that instantiates a Thread object, so it does. Then it executes its start() method. Since there is no more code after it, the main Thread exits here. On the other hand, the MyThread keeps running its code until it finishes its work.

Here, you have to keep in mind, when starting a thread, you must call the start() method, not the run() method. This is because the start method initializes the Thread and then calls the run() method. So, that means the platform that constructs the Thread calls the run method, not us as programmers. This information is very crucial to remember.

The above code will result following output:

Creating a new thread from : Thread[main,5,main]
Leaving from: Thread[main,5,main]
Executing code from: Thread[Thread-0,5,main]
Hello world

So, the steps are:

Create a class extending the java.lang.Thread class
Override the run() method in it.
Put the code that you want to be executed by this Thread in the run method.
Create an instance of this class and then call start() method of its instance. That’s it.

The other way is to have an implementation of the Runnable interface. For example:

package com.bazlur;

public class MyRunnable implements Runnable{
 @Override
 public void run() {
  System.out.println("Executing code using Runnable from: " + Thread.currentThread());
  System.out.println("Hello world");
 }
}

In the above class, we have implemented the runnable interface, and put our desired code in the run method.

The next steps is to create an instance of java.lang.Thread. We will put an instance of the MyRunnable class as an argument to the constructor of the java.lang.Thread. Then we call the start method:

package com.bazlur;

public class Playground {
 public static void main(String[] args) {
  System.out.println("Creating a new thread from : " + Thread.currentThread());

  var myRunnable = new MyRunnable();
  var thread = new Thread(myRunnable);
  thread.start();
  System.out.println("Leaving from: " + Thread.currentThread());
 }
}

The above code will result following output:

Creating a new thread from : Thread[main,5,main]
Leaving from: Thread[main,5,main]
Executing code using Runnable from: Thread[Thread-0,5,main]
Hello world

So, the steps are:

Create a class that implements a java.lang.Runnable interface.
Put your desired code in the run() method.
Create an instance of the class that implements the Runnable interface.
Use this instance as an argument of java.lang.Thread’s constructor and create an instance of it.
Call the start() method of the newly created instance of Thread.

That’s it.

Alternatively, you can use an anonymous inner class, and put this as an argument of the Thread’s constructor. Example:

var thread = new Thread(new Runnable() {
@Override
 public void run() {
  System.out.println("Executing code using Runnable from: " + Thread.currentThread());
  System.out.println("Hello world");
 }
});
thread.start();

Or, even, you can use lambda expression, since the Runnable interface has a SAM (single abstract method). Example:

var thread = new Thread(() -> {
 System.out.println("Executing code using Runnable from: " + Thread.currentThread());
 System.out.println("Hello world");
});
thread.start();

That’s it for today!

Don’t Forget to Share This Post!

Be sure of using Fork/Join common pool; they are daemon threads

A N M Bazlur Rahman — Sat, 03 Jul 2021 10:42:00 +0000

There are two kinds of threads in java-

user thread and
daemon thread

The user threads are priority threads. The user thread dies when it completes its work. So if not terminated by any external means, the thread will live until it finishes its work. On the other hand, daemon threads are created from a user thread and serve the user thread. So a daemon thread may die without completing its work if the user thread dies from which it was created.

Java program starts from the main method, and the main method starts with the main Thread. Let’s see an example-

package com.bazlur;

import java.util.concurrent.TimeUnit;

public class Day024_Playground {
    public static void main(String[] args) {
        var thread = new Thread(() -> {
            while (true) {
                //this thread is supposed to be running forever
                sleep(1);
                System.out.println(Thread.currentThread().getName()
                        + " is daemon? "
                        + Thread.currentThread().isDaemon());
            }
        });

        thread.setDaemon(true);
        thread.start();

        System.out.println("Running from main method");
        sleep(5);
        System.out.println("Done! will die now");
    }

    private static void sleep(int second) {
        try {
            TimeUnit.SECONDS.sleep(second);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

In the above code, we have created a new thread from the main method. The Thread is created from a user thread, which is basically the main Thread. Inside the Thread, we have an infinite loop. This means this Thread will keep running forever until it is stopped by an external means.

However, we marked it as a daemon thread. That means this it will keep running as long as the main Thread is alive.

The main Thread creates this new Thread, sleeps, then prints a statement and then dies. So immediately, the daemon thread will die.

If you run the above code, you will get the following output-

main method is running from Thread [main,5,main]
Running from main method
Thread-0 is daemon? true
Thread-0 is daemon? true
Thread-0 is daemon? true
Thread-0 is daemon? true
Done! will die now

Nothing will print will anymore.

We have learned about daemon thread so far. Let’s learn something else now-

Java has a new construct called CompletableFuture. Using it, we can execute a piece of code asynchronously.

There are a few factory methods in it which we can use easily. For example- runAsync(), supplyAsync() . Example-

    CompletableFuture<?> future = CompletableFuture.runAsync(() -> {
            System.out.println("Running asynchronously!");
        });

Or in case we need a value from it -

CompletableFuture<Integer> meaningOfLife = CompletableFuture.supplyAsync(() -> {
    return 42;
});

Now the question is, under which Thread these methods get executed?

The answer is, they get executed by Fork/Join Common pool.

If you run the following code in your main method-

package com.bazlur;

import java.util.concurrent.CompletableFuture;

public class Day024_Playground2 {
    public static void main(String[] args) {

        CompletableFuture.runAsync(() -> {
            System.out.println("Running asynchronously!");
            System.out.println("from " + Thread.currentThread());
        });

    }
}

You should get the following-

Running asynchronously!
from Thread[ForkJoinPool.commonPool-worker-19,5,main]

However, if your program has only the above code and nothing else in the main method, you may not get anything at all. Nothing will print in the main method.

Seems puzzling, right?

To able to get a result, either you have to call a get() on the CompletableFuture as bellow-

package com.bazlur;

import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutionException;

public class Day024_Playground2 {
    public static void main(String[] args) throws ExecutionException, InterruptedException {

        CompletableFuture.runAsync(() -> {
            System.out.println("Running asynchronously!");
            System.out.println("from " + Thread.currentThread());
        }).get();
    }
}

The get() call is a blocking call, which means the main Thread will block here, and nothing from the main Thread will progress until the asynchronous block finishes.

If we have some other code in the main Thread, they will wait until this asynchronous block finishes its job, which in turn diminishes the asynchronicity.

Or, the main Thread lives longer than the asynchronous block. In that case we will defiantly get the result as expected.

package com.bazlur;

import java.util.concurrent.CompletableFuture;

public class Day024_Playground2 {
    public static void main(String[] args) throws InterruptedException {

        CompletableFuture.runAsync(() -> {
            System.out.println("Running asynchronously!");
            System.out.println("from " + Thread.currentThread());
        });

        System.out.println("Doing some important work!");
        Thread.sleep(1000);
    }
}

Now if we run the above code, we will get the result. The reason is, the main Thread lives longer than the CompletableFuture. Assuming the CompletableFuture won’t take longer than 1000 milliseconds.

From the above discussion, we can conclude that the ForkJoinPool.commonPool holds the daemon threads. If they were user threads, they would finish their job; it wouldn’t matter if the main Thread finishes it works or not.

Let’s see if this is the case or not?


package com.bazlur;

import java.util.concurrent.CompletableFuture;

public class Day024_Playground2 {
    public static void main(String[] args) throws InterruptedException {

        CompletableFuture.runAsync(() -> {
            System.out.println("Running asynchronously!");
            System.out.println("from " + Thread.currentThread());
            System.out.println("Is it a daemon thread? "+ Thread.currentThread().isDaemon());
        });

        System.out.println("Doing some important work!");
        Thread.sleep(1000);
    }
}

The answer is an astounding yes. They are indeed daemon thread.

So what have we learned from this entire discussion?

If our main Thread doesn’t live longer than the daemon thread, we won’t get any result from the CompletableFuture. This is because they will not live to finish their work.

What can we do if we have a case where multiple CompletableFuture do some asynchronous jobs, but the user thread from which they are created dies early?

Instead of using the ForkJoin common pool, my solution would be to provide our own thread pool. We have executors.

package com.bazlur;

import java.util.concurrent.CompletableFuture;
import java.util.concurrent.Executors;

public class Day024_Playground2 {
    public static void main(String[] args) throws InterruptedException {

        var threadPool = Executors.newCachedThreadPool();

        CompletableFuture.runAsync(() -> {
            System.out.println("Running asynchronously!");
            sleep();
            System.out.println("from " + Thread.currentThread());
        }, threadPool);

        System.out.println("I'm Done!! going to die.");
        threadPool.shutdown();
    }

    private static void sleep() {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

In the above code, even the user thread dies, it won’t affect the CompletableFuture; it will finish its job and then it would die.

If we need such assurance, we should always provide executors to the CompletableFuture.

That’s for today! Cheers!

Project loom: the light at the end of the tunnel

A N M Bazlur Rahman — Sat, 03 Jul 2021 07:18:48 +0000

This article was first published in bazlur.com

In this article, I'm going to write an echo server in multiple ways. The server will not do anything; it will just keep listening for connections on a port and echo back whatever is sent. Then I will compare which way wins.

Let's first write the single-threaded echo sever-

package com.bazlur;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.ServerSocket;

public class Day016 {
  public static void main(String[] args) throws IOException {
    if (args.length != 1) throw new IllegalArgumentException("Please specify port");
    var port = Integer.parseInt(args[0]);

    var serverSocket = new ServerSocket(port);
    System.out.println("Started server on port " + port);

    while (true) {
      try (var socket = serverSocket.accept();
           var in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
           var out = new PrintWriter(socket.getOutputStream(), true)) {
        String line;
        while ((line = in.readLine()) != null) {
          out.println(line.toUpperCase());
        }
      } catch (IOException e) {
        System.out.println("Was unable to establish or communicate with client socket:" + e.getMessage());
      }
    }
  }
}

The above code is simple and intuitive. We have used a ServerSocket that listens to a port and waits for an incoming connection. Whenever a client connects to it, it reads whatever is sent to it and replies back.

The only problem is, it cannot handle multiple connections simultaneously. If one client connects to it, no other will be able to make it to the server at that particular time. Once that specific client disconnect, other will get a chance.

However, we can change the experience just by allowing multiple threads to handle each connection here.
Let's look at the code-

package com.bazlur;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.concurrent.Executors;

public class Day017 {
  public static void main(String[] args) throws IOException {
    if (args.length != 1) throw new IllegalArgumentException("Please specify port");
    var port = Integer.parseInt(args[0]);

    var executorService = Executors.newCachedThreadPool();
    var serverSocket = new ServerSocket(port);
    System.out.println("Started server on port " + port);

    while (true) {
      var socket = serverSocket.accept();
      executorService.submit(() -> handle(socket));
    }
  }

  private static void handle(Socket socket) {
    try (socket;
         var in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
         var out = new PrintWriter(socket.getOutputStream(), true)) {
      String line;
      while ((line = in.readLine()) != null) {
        out.println(line.toUpperCase());
      }
    } catch (IOException e) {
      System.out.println("Was unable to establish or communicate with client socket:" + e.getMessage());
    }
  }
}

In the above code, we haven't done anything extraordinary. We have just created a ThreadPool using Executors, and whenever a client connects, we put that in a thread to handle that connection.
This server will do just fine dealing with many connections simultaneously. However, we are not just happy with the word many. We want to know exactly how many connections it can handle.

The answer lies in how many threads we can spawn. It is certainly not limited by the socket. Because we know modern OS practically can handle millions of open sockets at a time. So let's rewrite the question again- Can OS handle such an amount of Threads?

Well, the answer is no. Threads are limited and heavy. Let's find out how much we can write a simple java program.

package com.bazlur;

import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.LockSupport;

public class ThreadCount {
  public static void main(String[] args) {
    AtomicInteger threadCount = new AtomicInteger();
    for (; ; ) {
      Thread thread = new Thread(() -> {
        var count = threadCount.incrementAndGet();
        System.out.println("count = " + count);
        LockSupport.park();
      });
      thread.start();
    }
  }
}

This little program will demonstrate how many threads we can create on a machine.
We can conclude that we are limited by the number of threads we can have and that many connections we can handle simultaneously.

Now the bigger question is, is there any alternative solution to it? We cannot have more threads; what else we can do to achieve an outstanding throughput.

Well, the answer is Non-Blocking IO. While doing the IO operation, the relationality is that most threads are just waiting idle, doing nothing. It connects to a client, and the client keeps communicating with a dedicated thread. But the communication is slow, and most of the time, the thread is idle, sitting there doing nothing. Why not use this thread's idle time to serve other clients.
That seems to be a fantastic idea. Let's do this.

package com.bazlur;

import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import java.util.*;
import java.util.concurrent.ConcurrentLinkedDeque;

public class Day018 {
  static Map<SocketChannel, Queue<ByteBuffer>> pendingData = new HashMap<>();

  public static void main(String[] args) throws IOException {
    if (args.length != 1) throw new IllegalArgumentException("Please specify port");
    var port = Integer.parseInt(args[0]);

    ServerSocketChannel socketChannel = ServerSocketChannel.open();
    socketChannel.bind(new InetSocketAddress(port));
    socketChannel.configureBlocking(false);

    var selector = Selector.open();
    socketChannel.register(selector, SelectionKey.OP_ACCEPT);

    while (true) {
      var select = selector.select();
      if (select == 0) continue;
      var selectionKeys = selector.selectedKeys();
      var iterator = selectionKeys.iterator();

      while (iterator.hasNext()) {
        SelectionKey key = iterator.next();
        if (key.isValid()) {
          if (key.isAcceptable()) {
            accept(key);
          } else if (key.isReadable()) {
            read(key);
          } else if (key.isWritable()) {
            write(key);
          }
        }
        iterator.remove();
      }
    }
  }

  private static void accept(SelectionKey selectionKey) throws IOException {
    var channel = (ServerSocketChannel) selectionKey.channel();
    var sc = channel.accept(); //never null
    System.out.println("Connected: " + sc);
    pendingData.put(sc, new ConcurrentLinkedDeque<>());
    sc.configureBlocking(false);
    sc.register(selectionKey.selector(), SelectionKey.OP_READ);
  }

  private static void read(SelectionKey selectionKey) throws IOException {
    var channel = (SocketChannel) selectionKey.channel();
    var byteBuffer = ByteBuffer.allocateDirect(80);
    var read = channel.read(byteBuffer);
    if (read == -1) {
      channel.close();
      pendingData.remove(channel);
      return;
    }

    if (read > 0) {
      processBuffer(byteBuffer);
      pendingData.get(channel).add(byteBuffer);
      selectionKey.interestOps(SelectionKey.OP_WRITE);
    }
  }

  private static void write(SelectionKey selectionKey) throws IOException {
    var channel = (SocketChannel) selectionKey.channel();
    var queue = pendingData.getOrDefault(channel, new ArrayDeque<>());
    while (!queue.isEmpty()) {
      var buff = queue.peek();
      if (buff.position() != buff.limit()) {
        buff.flip();
      }
      var written = channel.write(buff);
      if (written == -1) {
        channel.close();
        pendingData.remove(channel);
        return;
      }
      if (buff.hasRemaining()) return;
      queue.remove();
    }
    selectionKey.interestOps(SelectionKey.OP_READ);
  }

  private static void processBuffer(ByteBuffer byteBuffer) {
    byteBuffer.flip();
    StringBuilder line = new StringBuilder();
    line.append(LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss", Locale.getDefault())))
            .append("<<server>>: ");

    for (int b = 0; b < byteBuffer.limit(); b++) {
      var b1 = byteBuffer.get(b);
      line.append(Character.toUpperCase((char) b1));
    }
    var s = line.toString();
    var bytes = s.getBytes();
    byteBuffer.clear();
    byteBuffer.put(bytes);
    System.out.println("Executing from: " + Thread.currentThread());
  }
}

The above code seems a lot complex than the earlier and a lot more lines than the previous codebase. However, with the above code, we can achieve whatever we want to achieve. This single-threaded would give us a better throughput. We can even make it even better if we throw a few more threads to it.

We achieved it, but with a complex programming model, which isn't easy. It has many other problems; one particular is that it will become harder to debug with this complex model.

Is there any other way?

Well, that's where we see the light at the end of the tunnel, the Project loom. It would enable just writing million virtual threads without making any effort, and the programming model would remain the same, and we will achieve the outstanding throughput we intended to. Let's see an example-

package com.bazlur;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.concurrent.Executors;

public class Day018_1 {
  public static void main(String[] args) throws IOException {
    if (args.length != 1) throw new IllegalArgumentException("Please specify port");
    var port = Integer.parseInt(args[0]);
    var serverSocket = new ServerSocket(port);
    System.out.println("Started server on port " + port);

    try (var executors = Executors.newVirtualThreadExecutor()) {
      while (true) {
        var socket = serverSocket.accept();
        executors.submit(() -> handle(socket));
      }
    }
  }

  private static void handle(Socket socket) {
    try (socket;
         var in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
         var out = new PrintWriter(socket.getOutputStream(), true)) {
      String line;
      while ((line = in.readLine()) != null) {
        out.println(line.toUpperCase());
      }
    } catch (IOException e) {
      System.out.println("Was unable to establish or communicate with client socket:" + e.getMessage());
    }
  }
}

The programming model is the same as we did earlier. We are just using a different Executor, that's it. But this would enable us to have millions of threads.

Cheers.

Java Thread Programming: Lesson 4

A N M Bazlur Rahman — Wed, 30 Jun 2021 05:12:00 +0000

Photo by Yagnik Sankhedawala on Unsplash

Previous articles :

Java Thread Programming: Lesson 1

Java Thread Programming: Lesson 2

Java Thread Programming: Lesson 3

In our previous article, I have discussed race conditions. A race condition happens in a critical section. In this article, I will discuss this critical section and why it happens when it happens.

Let’s begin.

We got some ideas from the previous articles a data can be shared among multiple threads. Multiple threads can read a shared data, and it has no consequences. When one of these threads tries to change/write to the shared data, the problem comes to the picture. An example would be the best approach to explain this-

package com.bazlur;

public class Day022 {
    public static void main(String[] args) throws InterruptedException {
        var account = new BankAccount(0);

        Runnable runnable = () -> {
            for (int i = 0; i < 1000; i++) {
                account.deposit(100);
                account.withdraw(100);
            }
        };

        var t1 = new Thread(runnable);
        var t2 = new Thread(runnable);

        t1.start();
        t2.start();

        t1.join();
        t2.join();

        System.out.println("Available balance: " + account.getBalance());
    }
}

final class BankAccount {
    private long initialAmount;

    BankAccount(long initialAmount) {
        this.initialAmount = initialAmount;
    }

    public void withdraw(long amount) {
        deposit(-amount);
    }

    public void deposit(long amount) {
        initialAmount = initialAmount + amount;
    }

    public long getBalance() {
        return initialAmount;
    }
}

In the above code, we have simulated a bank account. We have created two threads, and both of their deposit and withdraw 100 thousand times. According to our calculation, the initial balance was 0, which means it should zero in the end. I run the above code; that’s not what we would see. Each time it will print a different result. That’s means something wrong here.

Is it a visibility problem? What if both threads run in two different processors and update their value in the cache? If we add a volatile keyboard and would that solve the issue? We can try adding a volatile keyword, but it won’t solve the problem because this isn’t a visibility issue, something else. Let’s discuss that.

We know in a multi-threaded environment, the execution order of code isn’t predictable. While the first thread is depositing the money, the second thread might well withdraw the amount. While both threads contest to write the value to the same variable, one might get discarded, and the other can win. If one of these operations are missed, then we will have incorrect data. That’s a problem.

In fact, in our code, that’s precisely what is happening.

How do we resolve it?

Well, we have to make the writing operation atomic. Changing the variable has to be done in a way so that only one thread can do it at a time. That way, we can prevent this inconsistency. This is called the critical section. We have to guard this critical section.

We have to use a mutual exclusion so that no other thread can go into that section if a thread reaches into the critical section and make the changes. Once a get away from the critical section, only then will the other get a chance.

This mutual execution is done by a keyword called synchronized. This keyword instructs java to create a lock. When a thread reaches the critical section, and it tries to acquire the lock. If it can acquire the lock, it does the operation, and once done, it releases the lock. Meanwhile, the other threads try to acquire the lock and wait until it is released.

When only one thread is allowed to perform an operation, then the operation is called atomic. There are multiple ways to achieve this atomicity. The easiest one is, declaring the method synchronized. Example –

class BankAccount {
  private long initialAmount;

  BankAccount(long initialAmount) {
    this.initialAmount = initialAmount;
  }

  public synchronized void withdraw(long amount) {
    deposit(-amount);
  }

  public synchronized void deposit(long amount) {
    initialAmount = initialAmount + amount;
  }

  public synchronized long getBalance() {
    return initialAmount;
  }
}

When we use mutual exclusion with synchronized keyword or lock, it also ensures visibility. So we don’t need to use volatile here. We can even create our own lock object. For example-

final class BankAccount {
  private final Object lock = new Object();
  private volatile long initialAmount;

  BankAccount(long initialAmount) {
    this.initialAmount = initialAmount;
  }

  public void withdraw(long amount) {
    synchronized (lock) {
      deposit(-amount);
    }
  }

  public void deposit(long amount) {
    synchronized (lock) {
      initialAmount = initialAmount + amount;
    }
  }

  public long getBalance() {
    synchronized (lock){
      return initialAmount;
    }
  }
}

The above code does the same thing; only it doesn’t have the synchronized keyword in the method signature. When we use synchronized keyword in the method signature, it is effectively synchronizing to the object itself. With the synchronized block, we can have multiple lock objects inside a class. For example, a class may have multiple critical sections, and they may not be related to each other. We can certainly allow multiple threads to use this class that deal with different critical sections. In such a scenario, multiple locks would make sense.

However, in modern java, we have great APIs with many other functionalities and flexibility in how we lock. These modern concurrency APIs don’t use the synchronized keyword at all. The lock can be conditional, and based on the situation, we can lock and unlock. But that’s something we will discuss some other day. Let’s just implement the BankAccount class with the Lock API.

class BankAccount {
  private long initialAmount;
  private final Lock lock = new ReentrantLock();

  BankAccount(long initialAmount) {
    this.initialAmount = initialAmount;
  }

  public void withdraw(long amount) {
    lock.lock();
    try {
      deposit(-amount);
    } finally {
      lock.unlock();
    }
  }

  public void deposit(long amount) {
    lock.lock();
    try {
      initialAmount = initialAmount + amount;
    } finally {
      lock.unlock();
    }
  }

  public long getBalance() {
    lock.lock();
    try {
      return initialAmount;
    } finally {
      lock.unlock();
    }
  }
}

Or we can use the LockHelper from the previous article.

class BankAccount {
    private final Lock lock = new ReentrantLock();
    private volatile long initialAmount;

    BankAccount(long initialAmount) {
        this.initialAmount = initialAmount;
    }

    public void withdraw(long amount) {
        LockHelper.withLock(lock, () -> deposit(-amount));
    }

    public void deposit(long amount) {
        LockHelper.withLock(lock, () -> initialAmount = initialAmount + amount);
    }

    public long getBalance() {
        return LockHelper.withLock(lock, () -> initialAmount);
    }
}

That’s for today.

Cheers!!

Java Thread Programming: Lesson 3

A N M Bazlur Rahman — Mon, 28 Jun 2021 12:12:00 +0000

Photo by Wonderlane on Unsplash

Previous articles :

Java Thread Programming: Lesson 1

Java Thread Programming: Lesson 2

When we write a program, we test its correctness. If the program works according to our expectations, it builds confidence. If the same program runs in a multithread environment and produces the correct result, we call that piece of code thread-safe. Thread safety is critical; otherwise, we will end up having the wrong output, which is not desirable. In this article, we will discuss another problem towards ensuring thread safety.

In the previous article, we have discussed race condition. However, that is not the only problem we deal with when we work with java threads. Let us see an example-

package com.bazlur;

public class Day021 {
    static boolean running = true;

    public static void main(String[] args) {
        var t1 = new Thread(() -> {
            while (running) {
            }
            System.out.println("from the other side");
        });

        var t2 = new Thread(() -> {
            running = false;
            System.out.println("Hello");
        });
        t1.start();
        t2.start();
    }
}

Look at the above code, it used two threads, and they share data, which is a Boolean, running.

Note that the first thread has a while loop, and this loop will keep running until the variable running is true. After the loop, we have a print statement that prints a text. In the second thread, the first statement changes the running variable from true to false, and then it prints another text.

If you look at the program, at first sight, we would think it will print the following –

Hello
from the other side.

Nevertheless, in reality, it will not be the only case. It will produce a different result in different machines, even in the same machine, if we run repeatedly. Let me explain why-

In a single-threaded environment, the execution order of the code remains the same as the way it is written. However, it does not remain the same in a multithreaded environment. It depends on the thread scheduler, the processor and the interaction between two threads.

There are three possible outputs of this program-

In the first thread, the while loop will keep running. Until then, the following line will not be executed. However, when the second thread starts, the first thing it does is, change the value of the running variable. It breaks the while loop of the first thread, thus, it prints the “Hello.” Meanwhile, the second thread prints the “from the other side.”

Hello
from the other side

The loop inside the first thread will keep running, and the second thread will change the value and print the text, “from the other side,” and then the loop of the first thread will break and print the “Hello”.

from the other side
Hello

Most of us can imagine this far, but there is another possibility that is also trickiest. The first thread will keep running the loop forever, and although the second thread will change the value of running, making it false and print the text, the first thread will not see the changes. In such a case, the program’s output will be only- “from the other side.”

Now in which case it could happen that the first thread will not read the changes? Usually, we have multiple processors in our modern computer. Each processor has some caches along with them. They are called L1, L2, and L2 cache. The processor uses these caches to execute the program faster without going to the main memory each time. It might well happen that the two threads in the above program can run in two different processors, and each of them can cache the variable, running inside their L caches. If the second thread changes the value, the first thread will not see it because it keeps reading it from the caches. This is called a visibility problem. Although the value was updated, it was not visible to the other thread. This often called data race.

Now the question is, how do we fix it?

If we could prevent the thread from not reading from the caches, the fix is to read them constantly from the main memory. There is a keyword for that in java, which is volatile.

The above code will fix if we add this keyword before running.

package com.bazlur;

public class Day021 {
    static volatile boolean running = true;

    public static void main(String[] args) {
        var t1 = new Thread(() -> {
            while (running) {
            }
            System.out.println("from the other side");
        });

        var t2 = new Thread(() -> {
            running = false;
            System.out.println("Hello");
        });
        t1.start();
        t2.start();
    }
}

The above code will always produce the correct result.

Reading from and writing to cache is always cheap compare to the main memory. Thus, we should only use a volatile variable when we need to enforce the visibility of variables.

That is for today! Cheers.

Java Thread Programming: Lesson 2

A N M Bazlur Rahman — Sat, 26 Jun 2021 04:12:00 +0000

Previous article : Java Thread Programming: Lesson 1

Threads are easy and fun when we don’t have to share data. However, when multiple threads want to get hold of shared resources, things get a little messy.

In our previous article, we have seen a server being handed a thread to deal with a client. Let’s say we want to count how many clients the server was able to serve successfully? How are we going to do that? One easy way is, we can have a counter variable and increment it whenever a job is done successfully.

package com.bazlur.threads;

public class Counter {
  private long count;

  public Counter(long count) {
    this.count = count;
  }

  public void increment() {
    count++;
  }

  public long getCount() {
    return count;
  }
}

We will pass this Counter to each client handler, and when they are successful, the handler will increment it.

package com.bazlur.threads;

import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;

public class Playground {
  public static void main(String[] args) throws IOException {
    var serverSocket = new ServerSocket(4040);
    System.out.println("Started server on port " + 4040);

    Counter counter = new Counter(0);

    while (true) {
      var socket = serverSocket.accept();
      var thread = new Thread(() -> {
        handleClient(socket, counter);
      });
      thread.start();
    }
  }

  private static void handleClient(Socket socket, Counter counter) {
    //here we have code for handling a client
    counter.increment();
  }
}

So we have passed the counter reference to the handleClient() method, and it will increment it when the job is done and successful.

However, this might cause some issues. For example, when multiple threads try to increment on a count variable, some can end up incrementing simultaneously. What happens is, when a thread tries to change a value, it first read it and then changes it. Let’s assume at a point in time, thread A reads the value 32 and at the same time, another thread B reads the same value, which is 32. Now both will try to increment it, and they both ended up incrementing it to 33. In reality, it should be 34.

If this happens, one of the values will be written, and the other one would get lost, and we will end up with stale data. So let’s experiment with this hypothesis.

package com.bazlur.threads;

public class Playground {
  public static void main(String[] args) throws InterruptedException {

    Counter counter = new Counter(0);
    Thread thread1 = new Thread(() -> {
      for (int i = 0; i < 1_000; i++) {
        counter.increment();
      }
    });
    Thread thread2 = new Thread(() -> {
      for (int i = 0; i < 1_000; i++) {
        counter.increment();
      }
    });

    thread1.start();
    thread2.start();

    thread1.join();
    thread2.join();

    var count = counter.getCount();
    System.out.println("count = " + count);
  }
}

In the above code, we have created an instance of Counter and then create two threads.

Each will run 1000 times and increment the Counter. So if both threads have done their job, we will have 2000 as a value in the Counter.

In java, we start our program in the main method, and the main method runs under a thread called the main thread. Here, we have created two other threads from the main thread, and they are going to run separately.

When a thread finishes it’s work, it dies. Here, the main method can even finish its work before the other thread ends its work. Let’s look at the main method; it creates two threads, then starts those threads, finally invokes the getCount() method to get the count and print it. While the two threads are incrementing, if the main thread finishes its work, then we will never get the final count. Therefore, the main thread has to wait for the other two threads to complete their work. To do that, we call the join() method of the reference of the thread.

That’s why in the above code, we have used the following two lines-

thread1.join();
thread2.join();

Now the main thread will wait until these threads finish. Only after that, the main thread will print the count value.

Now let’s run the above code. According to our calculation, the value should be 2000.

However, it doesn’t matter how many times you run it; it will hardly be 2000. Every time it will print different results.

You could be a little puzzled at this point, but this is what it is supposed to be. The reason is, the two threads increment the Counter simultaneously, and it could happen that two threads increment the value at the same time. In such a case, one will win, and the other will be discarded, and we will end up with stale data. This is call contention. Whenever a shared variable is changed from multiple threads, this sort of situation emerges.

This is called a race condition.

We can avoid this if we could only allow one thread at a point in time when we want to change a value. We can do this by adding a lock to it.

Let’s change the counter class and add a look at its method -

package com.bazlur.threads;

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class Counter {
  private long count;
  private Lock lock = new ReentrantLock();

  public Counter(long count) {
    this.count = count;
  }

  public void increment() {
    lock.lock();
    try {
      count++;
    } finally {
      lock.unlock();
    }
  }

  public long getCount() {
    lock.lock();
    try {
      return count;
    } finally {
      lock.unlock();
    }
  }
}

Now, if we run the Playground.java, we will always get the correct result.

From this discussion, the conclusion that we can draw is, whenever data is shared into multiple threads, and they are changed, we have to put a locking; otherwise, they will produce stale data.

In the previous article, we have seen how we can improve our code using the execute-around pattern. We can use the same pattern in the Counter class and clean some boilerplate code.

class ConcurrentCounter {
  private long count;
  private final Lock lock = new ReentrantLock();

  public long incrementAndGet() {
    return withLock(lock, () -> ++count);
  }

  public long get() {
    return withLock(lock, () -> count);
  }
}

That’s for today, cheers!!

Java Thread Programming: Lesson 1

A N M Bazlur Rahman — Sat, 26 Jun 2021 04:01:00 +0000

When we run a java program, we are given an execution environment that runs our code one by one. When we have only one execution environment, things are pretty straightforward. All the code runs the same way we write. However, when we have many things to run simultaneously, this single environment will not help us much. That’s where Thread comes into the picture.

We can write our program in a way; it can do multiple things simultaneously in different threads. Each Thread is a unique execution environment.

Creating a thread is easy. In java, we have a class called Thread that can be instantiated and provided a job to it, and it will run independently. Let’s see an example-

package com.bazlur.threads;

public class Playground {
  public static void main(String[] args) {
    Thread thread1 = new Thread(() -> {
      System.out.println("Running from: " + Thread.currentThread());
    });

    Thread thread2 = new Thread(() -> {
      System.out.println("Running from: " + Thread.currentThread());
    });

    thread1.start();
    thread2.start();
  }
}

When we create a thread, we pass a lambda expression to its argument. In the expression, we put our code that we want to run independently.

In the above code, we have created two threads. Each Thread will run independently and simultaneously. Although we have started two threads one by one, we can never tell which one would run first. That’s the nature of the Thread. They are independent and depend on how the operating system schedules them to run.

So far, we have just seen how to create a thread and how to run them. They are super helpful when we have some independent work to be done. For example- we have to write a web server where multiple clients connect to it. If the server runs with a single thread, then at a time, it will be able only to serve one client. That’s not super useful. The server should handle multiple clients at a time, and that’s the point of having it.

Let’s see in the code-

package com.bazlur.threads;

import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;

public class Playground {
  public static void main(String[] args) throws IOException {
    var serverSocket = new ServerSocket(4040);
    System.out.println("Started server on port " + 4040);

    while (true) {
      var socket = serverSocket.accept();
      var thread = new Thread(() -> {
        handleClient(socket);
      });
      thread.start();
    }
  }

  private static void handleClient(Socket socket) {
    //here we have code for handling a client
  }
}

In the above code, the server keeps listening from clients, and whenever a client connects, it creates a new thread and passes the job into it. That’s how threads help us.

That’s for today, cheers!!

Let’s remove the boilerplate code with execute-around pattern

A N M Bazlur Rahman — Fri, 25 Jun 2021 04:01:00 +0000

In this article, I will first create a thread-safe stack from scratch with a traditional approach, and then I will refactor it with an execute-around design pattern.

Stack is a last-in-first-out (LIFO) data structure. It has two main methods, push and pop. Let’s create it –

package com.bazlur;

import java.util.Arrays;
import java.util.NoSuchElementException;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class ConcurrentStack<T> {
  private final Lock lock = new ReentrantLock();
  private T[] elements;
  private int size = -1;

  public ConcurrentStack() {
    this(10);
  }

  public ConcurrentStack(int initialCapacity) {
    this.elements = (T[]) new Object[initialCapacity];
  }

  public void push(T value) {
    lock.lock();
    try {
      growIfNeeded();
      elements[size] = value;
    } finally {
      lock.unlock();
    }
  }

  public T pop() {
    lock.lock();
    try {
      if (size == -1) {
        throw new NoSuchElementException();
      }
      trimToSizeIfNeeded();

      var element = elements[size];
      elements[size] = null;
      size--;
      return element;
    } finally {
      lock.unlock();
    }
  }

  private void growIfNeeded() {
    if (++size == elements.length) {
      grow();
    }
  }

  private void grow() {
    int newCapacity = elements.length * 2;
    elements = Arrays.copyOf(elements, newCapacity);
  }

  private void trimToSizeIfNeeded() {
    if (size < elements.length) {
      elements = Arrays.copyOf(elements, size + 1);
    }
  }
}

This is the most straightforward implementation, and it has many shortcomings; anyway, that’s beside the point.

Look at the push and pop method; one thing is very common: locking the lock and then unlocking it. This seems boilerplate, and it has nothing to do with the actual business logic of the stack.

Let’s move this boilerplate code to another place-

package com.bazlur;

import java.util.concurrent.locks.Lock;
import java.util.function.Supplier;

public class LockHelper {
  public static void withLock(Lock lock, Runnable runnable) {
    lock.lock();
    try {
      runnable.run();
    } finally {
      lock.unlock();
    }
  }

  public static <T> T withLock(Lock lock, Supplier<T> supplier) {
    lock.lock();
    try {
      return supplier.get();
    } finally {
      lock.unlock();
    }
  }
}

The first method takes a lock and a runnable. It does the locking and looking, and in between, it executes the run method of the runnable. The following method also takes a lock and a Supplier. In case we need to return something, that’s why we used Supplier here.

Let’s use these methods in the ConcurrentStack.

package com.bazlur;

import java.util.Arrays;
import java.util.NoSuchElementException;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class ConcurrentStack2<T> {
  private final Lock lock = new ReentrantLock();
  private T[] elements;
  private int size = -1;

  public ConcurrentStack2() {
    this(10);
  }

  public ConcurrentStack2(int initialCapacity) {
    this.elements = (T[]) new Object[initialCapacity];
  }

  public void push(T value) {
    LockHelper.withLock(lock, () -> {
      growIfNeeded();
      elements[size] = value;
    });
  }

  public T pop() {
    return LockHelper.withLock(lock, () -> {
      if (size == -1) {
        throw new NoSuchElementException();
      }
      trimToSizeIfNeeded();

      var element = elements[size];
      elements[size] = null;
      size--;
      return element;
    });
  }

  private void growIfNeeded() {
    if (++size == elements.length) {
      grow();
    }
  }

  private void grow() {
    int newCapacity = elements.length * 2;
    elements = Arrays.copyOf(elements, newCapacity);
  }

  private void trimToSizeIfNeeded() {
    if (size < elements.length) {
      elements = Arrays.copyOf(elements, size + 1);
    }
  }
}

Now our code is much cleaner and doesn’t’t have any of those boilerplates locking related code.

If we want to add another method in this class, we will use a similar pattern. –

public T peek() {
    return LockHelper.withLock(lock, () -> elements[size]);
}

We are executing our code around something that seems not present before our eyes, removing noise and bringing clarity. This is why it is called execute around design pattern, and it helps to remove a lot of similar boilerplate code.

That’s for today!

Cheers!!

for copy/paste pleasure: https://github.com/rokon12/100DaysOfJava/blob/main/src/main/java/com/bazlur/ConcurrentStack2.java

CompletableFuture made life easy, running things asynchronous

A N M Bazlur Rahman — Sun, 20 Jun 2021 04:10:40 +0000

Let’s assume you have to invoke two REST APIs and then combine the result. You can run them one by one and then accumulate the result. It looks easy. However, if each call takes up some time, the total time would be pretty significant.

However, we can reduce the time if we can run these two asynchronously, making them parallel. That’s where CompletableFuture comes into play.

Let’s see a code-


package com.bazlur;

import java.util.Optional;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutionException;
import java.util.stream.Collectors;
import java.util.stream.Stream;

public class Day014 {
  public static void main(String[] args) throws ExecutionException, InterruptedException {
    var stockExchangeService = new StockExchangeService();
    var futureCAD = CompletableFuture.supplyAsync(stockExchangeService::getBitcoinValueInCAD);
    var futureUSD = CompletableFuture.supplyAsync(stockExchangeService::getBitcoinValueInUSD);

    var combined = futureCAD.thenCombine(futureUSD, (cad, usd) -> Stream.of(cad, usd)
            .flatMap(Optional::stream)
            .collect(Collectors.joining(", ")));

    System.out.println("combined = " + combined.get());
  }
}

The stockExchange Service:

package com.bazlur;

import org.jsoup.Jsoup;
import org.jsoup.nodes.Element;

import java.io.IOException;
import java.util.Optional;

public class StockExchangeService {

  public static final String GOOGLE_FINANCE_QUOTE_BTC_CAD = "https://www.google.com/finance/quote/BTC-CAD";
  public static final String GOOGLE_FINANCE_QUOTE_BTC_USD = "https://www.google.com/finance/quote/BTC-USD";
  public static final String CAD_TEXT = "Bitcoin to Canadian dollar";
  public static final String USD_TEXT = "Bitcoin to United States Dollar";

  public Optional<String> getBitcoinValueInCAD() {
    return getBitConValue(GOOGLE_FINANCE_QUOTE_BTC_CAD, CAD_TEXT);
  }

  public Optional<String> getBitcoinValueInUSD() {
    return getBitConValue(GOOGLE_FINANCE_QUOTE_BTC_USD, USD_TEXT);
  }

  private Optional<String> getBitConValue(String url, String textToFind) {
    var connect = Jsoup.connect(url);
    try {
      var document = connect.get();
      var select = document.select("h2");
      return select.stream()
              .filter(element -> element.text().contains(textToFind))
              .map(Element::parent)
              .map(Element::text)
              .findFirst();
    } catch (IOException e) {
      return Optional.empty();
    }
  }
}

I have used JSoup to parse the text and exact the desired value from it.

for copy/paste pleasure: https://github.com/rokon12/100DaysOfJava/blob/main/src/main/java/com/bazlur/Day014_2.java