Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
In a previous post, we discussed the history of threading and provided instructions on how to initiate and begin a thread.
Let's take a look at an illustration of how we might leverage threads to our advantage in this article.
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.
Thread is the heart of the Java programming language. When we run a Hello World Java program, we run on the main thread. And then, we can definitely create threads easily as we need to compose our application code to be functional, responsive, and performant at the same time. Think about a web server; it simultaneously handles hundreds of requests at the same time. In Java, we achieve this using multiple threads. While threads are helpful, it is dreadful to many of the developers. That's why in this article, I will share five interesting threading concepts that the beginner and intermediate developers might not know.
When we write a code, we assume the code will be executed exactly the way we write it. However, in reality, this is not the case. The Java compiler may change the execution order to optimize it if it can determine that the output won't change in single-threaded code.
Multithreading chapters are the most difficult to understand and use in Java. Unfortunately, there are not that many sources where you can get all the answers. Meanwhile, concurrency knowledge is critically important. In this article, I explain the core aspects of multithreading that every Java developer has to know. In this part, we start with the Thread and Runnable subject.
Multithreading knowledge almost certainly is the subject of interviews for senior Java positions. Without a clear understanding of multithreading with and without hands-on experience, you most likely will fail.
When I was working in software development back in the 1990s, nearly all the software libraries that I worked on made use of event loops. This was because at the time most hardware had just one single CPU. Back in the day, I remember the excitement when threads were introduced into our development framework. It was revolutionary that we could now run two things at once, or rather appear to run two things at once, since a lot of the hardware at that time still only had a single core, and hence our threaded code was never really truly concurrent.
Over the years I've had mixed feelings about threads. Some of the most challenging systems that I’ve maintained have suffered from the overuse or misunderstood impact of concurrency. Even today I have discussions around if a piece of code is truly thread-safe and although the libraries (for example, the Java Concurrency Library) have made massive improvements reducing the burden of developing with threads, it is still somewhat of a challenge to ensure that we are not calling code which is not thread-safe when we have assumed it is. This is something that is generally not easily picked up by either static analysis or software compilers.
Thread creation is a well-known process and there are two ways to create it:
Let's implement both options:
You might have seen this question being asked in so many interviews.
We are going to achieve this using Java 8 completable future and executor service.
I believe, the title is very abstract but clearly explains the purpose. The concurrency package is the boss when it's come to asynchronous programming. Of course, this is the continuation of my previous articles on asynchronous programming.
We have seen creating Threads and make use of Executor Framework for the Thread management. Also, We look at how to submit a task and how is it processed internally in the executor. But we haven't seen how to check the status or getting the result etc.
As a backend engineer, we face situations to process the data asynchronously. Today let's see how it's done in java and various way to do it.
Starting from Thread, Runnable, Callable<T>, Future<T> (and its extended ScheduledFuture<T>), CompletableFuture<T>, and of course, ExecutorService and ForkJoinPool. We will see all of them, but one by one.
When I first started to learn Spring, two “difficult” questions crossed my mind:
Hello, readers! In this blog, we are going to explore thread confinement, what it means, and how we achieve it. So, let’s dive straight into it.
Most concurrency problems occur only when we want to share a mutable variable, or mutable state, between threads. If a mutable state is shared between multiple threads, then all of them will be able to read and modify the value of the state, thus resulting in incorrect or unexpected behavior. One way to avoid this problem is to simply not share the data between the threads. This technique is known as thread confinement and is one of the simplest ways of achieving thread safety in our application.
This article is intended to explain the important use case of sharing data across the ThreadGroups in JMeter where most developers/test engineers face these challenges. Let's start with the example use case below:
As part of this material:
On page 54 in his distinguished book "Java Concurrency In Practice," Brian Goetz describes how objects can be safely shared across threads. He lists four options:
In this post, I will describe a variant that falls into the fourth category. The objects shared are not thread-confined, not read-only, and aren't synchronized internally. I am going to use a read-write lock to guard the object's state. As the presented technique is highly concurrent, it will not require synchronized blocks and gauruntees that no needless thread contention will slow down application performance. Without using synchronized, it is still garanteed that any change will be visible across all threads that share the object instances; this is achieved by applying certain rules to the shared objects' mutable state.
What does the java.net.SocketInputStream.socketRead0() API do? Why is it showing up frequently in thread dumps? Why is it reported in thread dump analysis tools like fastThread.io? Is it something that I need to be concerned about? What are the potential solutions to this problem? Let’s find answers to these questions.
It’s always easy to remember new concepts through real-life analogies. Suppose you are calling your wife or girlfriend on the phone. Once the call gets connected, if she is in a good mood, you will get the response: “Hello, Honey, how are you?” If your call got connected when she is in middle of doing work (say she is in her office, picking up kids, at the gym, etc.), there might be a delay in her response: “Hello, Honey...” Suppose your call got connected when she is upset. You might get a response after several seconds/minutes. So, the time you are waiting since the moment call got connected until the moment you hang up the call is basically the socketRead0() API. (Thanks to Douglas Spath from IBM for giving this beautiful example to explain this SocketRead0() API.)