But when we perform tasks that require heavy processing, Node.js's performance can start to decline. Many people mistakenly think that Node.js isn’t good or that JavaScript is flawed. But there’s actually a solution. JavaScript can also be used effectively with multi-threading.

In this article, we will focus on the backend: specifically, how to implement multi-threading on the server side using Node.js.

Here’s What We’ll Cover

1. Prerequisites

2. Project Setup with ExpressJS

   • 1. Create a New Project Folder

   • 2. Initialize a Node.js Project

   • 3. Install Express.js

   • 4. Optional: Install Nodemon for Development

   • 5. Create the Main Server File

   • 6. Run the Project

3. Understanding the Problem

   • Observing the Behavior

   • Why Does This Happen?

4. Understanding JavaScript Execution

   • How Libuv Works

   • Asynchronous Nature of Node.js

5. The CPU-Intensive Problem

6. How to Implement Worker Threads

   • Communication Between Threads

   • Setting Up Worker Communication

7. How to Optimize with Multiple Cores

   • Checking How Many Cores Your System Has

   • Utilizing Multiple Cores for Faster Execution

8. How to Implement Multi-Core Optimization

   • Understanding the Code Line by Line

   • Thread Planning and Configuration

   • Dividing Work Across Multiple Workers

   • Handling Complex Tasks

9. Performance Comparison

   • Testing Results

   • Performance Metrics

   • Key Takeaways

10. Summary

    • The Multi-Core Challenge

    • Discovering Available Cores

    • Asynchronous Worker Creation

    • Multi-Threaded Implementation Strategy

    • Key Concepts Recap

    • What We Learned

11. Final Words

12. Additional Resources

Prerequisites

To follow along and get the most out of this guide, you should have:

1. Basic JavaScript (ES6-style) knowledge

2. Familiarity with Node.js fundamentals

3. Web-server basics using Express (or similar)

4. Understanding of blocking vs non-blocking operations in Node.js / JavaScript

5. Comfort with asynchronous code (Promises / async/await) and event-based handling

6. Setting up a simple development environment with Node.js

I’ve also created a video to go along with this article. If you’re the type who likes to learn from video as well as text, you can check it out here:

Project Setup with ExpressJS

In this section, we will go through a detailed, beginner-friendly setup for a Node.js project using Express. This guide explains every step, so even if you are new to Node.js, you can follow along easily.

1. Create a New Project Folder

Start by creating a new folder for your project. Open your terminal or command prompt and run:

mkdir node-worker-threads
cd node-worker-threads

• mkdir node-worker-threads: This command creates a new folder named node-worker-threads.

• cd node-worker-threads: Moves you into the newly created folder where all project files will be stored.

Think of this folder as the home for your project.

2. Initialize a Node.js Project

Every Node.js project needs a package.json file to manage dependencies and scripts. Run:

npm init -y

• npm init creates a package.json file.

• The -y flag automatically fills in default values, saving you time.

After this, you will see a package.json file in your project folder. This file keeps track of all packages and configurations.

3. Install Express.js

Express is a lightweight web framework for Node.js. Install it with:

npm install express

This adds Express to your project and allows you to create routes, handle requests, and send responses easily.

4. Optional: Install Nodemon for Development

Nodemon automatically restarts your server whenever you make changes. This is very useful during development.

npm install -D nodemon

The -D flag installs Nodemon as a development dependency.

Next, Update package.json scripts:

{
  "scripts": {
    "dev": "nodemon index.js"
  }
}

Now you can start the server with:

npm run dev

This will automatically restart your server whenever you make code changes.

5. Create the Main Server File

Create a file called index.js. This will be the main entry point of your application:

touch index.js

Open index.js and add the following code:

// index.js 

const express = require("express");

const app = express();
const port = process.env.PORT || 3000;

// Non-blocking route
app.get("/non-blocking", (req, res) => {
  res.status(200).send("This page is non-blocking.");
});

// Blocking route using Worker Threads
app.get("/blocking", (req, res) => {
  let result = 0;
  for (let i = 0; i < 1000000000; i++) {
    result++;
  }
  res.status(200).send(`Result is ${result}`);
});

// Start the server
app.listen(port, () => {
  console.log(`App listening on port ${port}`);
});

Here’s what’s going on in this code:

• express: To create the server.

• Worker: To run CPU-intensive tasks in a separate thread.

• /non-blocking route: Sends a quick response immediately.

• /blocking route: Runs a Worker thread to handle heavy computation.

• app.listen: Starts the server on port 3000 (or environment port).

Don’t worry if all of this isn’t perfectly clear at the moment. We’ll explore everything in greater detail as we move forward. Get ready, because we’re going to break down each part step by step in the simplest way possible.

6. Run the Project

Start the server using Nodemon:

npm run dev

Or without Nodemon:

node index.js

Visit these URLs in your browser:

• http://localhost:3000/non-blocking displays a simple non-blocking message.

• http://localhost:3000/blocking executes a CPU-intensive task using Worker Threads.

Congratulations! Your Node.js project with Express is fully set up and ready for development.

Understanding the Problem

We have already set up a basic Express.js application, which is essentially a Node.js app. In this application, we have defined two routes:

1. /non-blocking

2. /blocking

The /non-blocking route is straightforward: it simply returns a text response saying, "This page is non-blocking."

On the other hand, the /blocking route contains a heavy computation. It runs a loop up to one million numbers, calculates the sum of all these numbers, and then returns the result.

Finally, the application is set to run on port 3000 using app.listen.

Observing the Behavior

If you open your browser and visit the http://localhost:3000/non-blocking URL, it works perfectly fine and responds immediately.

But if you visit the http://localhost:3000/blocking URL, the page keeps loading and doesn’t respond right away.

What's even more interesting is that if you try to access http://localhost:3000/non-blocking while /blocking is still running, it also becomes unresponsive.

This demonstrates a key concept: while the /blocking route is executing, even the /non-blocking route cannot respond. In other words, the heavy computation in /blocking blocks the Node.js event loop, affecting all other routes.

Why Does This Happen?

The reason lies in how Node.js works. Node.js is essentially a JavaScript runtime, and as we know, JavaScript is a single-threaded programming language. Naturally, Node.js also runs on a single thread by default.

So, where does the problem arise? When you execute the /blocking route, all the JavaScript code runs on the main thread. During this time, the main thread is completely busy or blocked. As a result, if another user tries to access the /non-blocking route, they won't get any response because the main thread is still occupied with the previous task.

This is why many people mistakenly think that JavaScript is weak because it's single-threaded. But this perception is not entirely accurate. With the right approach and techniques, JavaScript can also be used in a multi-threaded way, allowing you to handle heavy computations without blocking other operations.

Understanding JavaScript Execution

Let's think about the main thread where JavaScript primarily runs. You might ask, where exactly does JavaScript execute? JavaScript runs inside the JavaScript engine, which is responsible for converting JavaScript code into machine code.

In the case of Node.js, it runs on the V8 engine, which is the same engine used in Google Chrome. The V8 engine operates entirely on a single thread, meaning all JavaScript code executes within just one main thread.

Now, you might wonder: are there any threads other than the main thread? The answer is yes. Apart from the main thread, there are additional threads used to handle different types of tasks. The management and implementation of these threads are handled by a special library called Libuv.

How Libuv Works

Libuv is designed to work alongside the V8 Engine. While the V8 Engine executes JavaScript code on the main thread, additional threads are used to handle different types of tasks. For example, operations like database queries, network requests, or file read/write tasks are handled by these extra threads, and the Libuv library manages and coordinates them.

Whenever we perform such tasks, they are actually executed on these extra threads outside the main thread. Libuv instructs the V8 Engine on how to handle these tasks efficiently. These tasks are commonly referred to as Input/Output operations, or I/O operations for short. In other words, when performing file read/write, database queries, or network requests, these I/O operations are executed on separate threads without blocking the Main Thread.

But if we have tasks like a large for-loop in our earlier example, or any operation that primarily requires CPU processing, they do not fall under I/O operations. In such cases, the task must be executed on the main thread, which inevitably blocks it until the task is completed.

Asynchronous Nature of Node.js

Consider a scenario where a client sends a request to the main thread, and this request requires a database query to be executed.

When the user sends such a request, the database query is sent to the database, but importantly, it does not block the main thread. Instead, Libuv handles the database query on a separate thread, keeping the Main Thread free to handle other tasks.

In this situation, if another user sends a request that does not involve any database query or I/O operation, it can be executed immediately on the Main Thread. As a result, this second user receives a response without any delay.

Once the database query running on the separate thread completes, the result is returned to the Main Thread, which then sends it back as a response to the original user. This approach ensures that users receive their output efficiently, and the main thread remains available for other tasks.

This entire process represents the asynchronous nature of JavaScript and Node.js. Tasks are not executed synchronously – instead, they run asynchronously. One user's request can be processed on a separate thread while other users continue to interact with the server seamlessly. This is how Node.js maintains high performance and responsiveness even under multiple simultaneous requests.

The CPU-Intensive Problem

So, this is how everything works effectively. Now, the question is, what happens if the main thread has a task that doesn't require any database access for a user's request but demands heavy CPU processing? In that case, the main thread will get blocked.

Let's say a task on the main thread is consuming a lot of CPU. If we execute it directly on the main thread, the event loop will get blocked, and other requests won't be able to be processed.

This is where worker threads come into play in Node.js. With worker threads, we can spin up a new thread outside the main thread to handle CPU-heavy operations separately. As a result, the main thread stays free, allowing other requests to be processed immediately.

In other words, by using worker threads, we can run CPU-bound tasks asynchronously, ensuring that the server's throughput and responsiveness are not affected.

How to Implement Worker Threads

If we take a look at our previous index.js file, the task in the /blocking route handler is running entirely on the main thread, which is why it causes blocking. So, how can we solve this problem? The solution is to use Node.js's built-in worker threads module.

There is no need to install any external package, as worker threads is a core module of Node.js.
We can directly require the Worker class from the worker_threads module and create a new worker thread.

// index.js

const express = require("express");
const { Worker } = require("worker_threads");

const app = express();
const port = process.env.PORT || 3000;

// Non-blocking route
app.get("/non-blocking", (req, res) => {
  res.status(200).send("This page is non-blocking.");
});

// Blocking route using Worker Threads
app.get("/blocking", (req, res) => {
  const worker = new Worker("./worker.js");

  let result = 0;
  for (let i = 0; i < 1000000000; i++) {
    result++;
  }
  res.status(200).send(`Result is ${result}`);
});

// Start the server
app.listen(port, () => {
  console.log(`App listening on port ${port}`);
});

How it works:

• Inside the /blocking route handler, we create a new worker using new Worker() and provide a file path.

• This file (worker.js) contains the CPU-heavy task that we want the worker to execute.

• For example, our heavy for-loop is moved into this separate file.

We create a new file named worker.js and paste the loop there:

// worker.js

for (let i = 0; i < 1000000000; i++) {
  result++;
}

When we pass the path to worker.js while creating the Worker, Node.js starts a new thread.

This new thread executes the CPU-intensive task independently, keeping the main thread free to handle other incoming requests.

By doing this, the application becomes more responsive and can handle multiple requests without blocking.

Communication Between Threads

In Node.js, we have the main thread and additional worker threads. To coordinate tasks between them, we can use a messaging system. Essentially, all results eventually need to reach the main thread. Otherwise, we won't be able to provide any output to the user.

For example, suppose you assign a task to Thread B and another task to Thread C. When these threads complete their tasks, they must inform the main thread. They do this by sending messages through the messaging system.

Think of it like exchanging messages in an inbox: Thread C sends a message directly to the main thread once its task is finished. Through this communication, worker threads notify the main thread about task completion and send any necessary data.

This is exactly the mechanism we will use in our example to handle CPU-heavy tasks with worker threads, ensuring that the main thread remains free and responsive.

Setting Up Worker Communication

So, we’ve created a worker.js file. Now, the question is, how do we inform the main thread about the task being done in this file?

To achieve this, we extract parentPort from the built-in worker_threads module in Node.js. The parentPort is a special object that allows communication between the worker thread and the main thread. It acts as a bridge: whenever the worker completes a task, it can send the result back to the main thread through this channel.

Once the task is complete, we use the method parentPort.postMessage(result) to send the final data. In other words, we’re posting a message to the parent thread, and in our case, that message is the computed result of our loop.

Here’s the full code for the worker.js file:

// worker.js

const { parentPort } = require("worker_threads");

let result = 0;
for (let i = 0; i < 10000000000; i++) {
  result++;
}

parentPort.postMessage(result);

In this example:

• We import parentPort from worker_threads.

• We perform a heavy task – a loop that counts up to 10 billion.

• After finishing the loop, we send the result back to the main thread using parentPort.postMessage(result).

This is how communication between the worker thread and the main thread takes place in Node.js.

Now, the question is, once we send the data from the worker, how do we receive it in the /blocking handler of our index.js file?

To do this, we need to set up a listener inside the handler. For that, we use the worker.on() method.

So, what exactly are we listening for? We listen for the "message" event – just like we listen for onClick or other events in JavaScript.

The first parameter of worker.on() is the event name ("message"), and the second parameter is a callback function. Inside that callback, the first argument represents the data we receive from the worker.

Once we receive the data, we can send it back to the browser as a response using:

// index.js 

// Inside the `/blocking` route handler, we listen for messages from the worker thread.
// Whenever the worker completes its task and sends a message, 
// the callback receives the data as the `data` parameter.
// We then send this data back to the client as an HTTP response with status code 200.

worker.on("message", (data) => {
  res.status(200).send(`Result is ${data}`);
});

Explanation:

• worker.on("message", callback) listens for messages sent from the worker thread using parentPort.postMessage().

• The data parameter contains the result sent by the worker.

• Using res.status(200).send(...), we send the computed result back to the browser.

• This allows the heavy computation to happen in a separate thread, keeping the main thread free and responsive.

At the same time, we should also handle possible errors.

If any error occurs inside the worker, we can listen for it using the "error" event in the same way:

// index.js 

// In the `/blocking` route handler, we listen for any errors that occur inside the worker thread.
// If an error occurs, the callback receives the error object `err`,
// and we send it back as an HTTP response with status code 400.

worker.on("error", (err) => {
  res.status(400).send(`An Error occurred : ${err}`);
});

Explanation:

• worker.on("error", callback) listens specifically for errors inside the worker thread.

• The err parameter contains details about what went wrong in the worker.

• Using res.status(400).send(...), we return the error to the client so the request doesn’t hang silently.

Here’s how the complete code looks:

// index.js

const express = require("express");
const { Worker } = require("worker_threads");

const app = express();
const port = process.env.PORT || 3000;

// Non-blocking route
app.get("/non-blocking", (req, res) => {
  res.status(200).send("This page is non-blocking.");
});

// Blocking route using worker threads
app.get("/blocking", (req, res) => {
  const worker = new Worker("./worker.js");

  worker.on("message", (data) => {
    res.status(200).send(`Result is ${data}`);
  });

  worker.on("error", (err) => {
    res.status(400).send(`An Error occured : ${err}`);
  });
});

// Start the server
app.listen(port, () => {
  console.log(`App listening on port ${port}`);
});

Once this is set up, you'll see a dramatic change. The /blocking route is loading, but even while it's loading, repeatedly refreshing the /non-blocking route works perfectly without any issues!

Now notice, the /non-blocking route is accessible, which means even though the /blocking route is still running, it doesn't affect anything. So, we've successfully solved this problem. We moved the main task to a separate thread outside the main thread. What does this mean? The main thread created a new worker thread and assigned the CPU-heavy task to it. The new thread now works independently, while the main thread remains free.

Finally, when the new thread completes its task, it also becomes free. Then, through the messaging system, the new thread informs the main thread, "Your data is ready, here's your data." The main thread receives this data and sends it to the client as a response.

Therefore, the tasks that were automatically handled on separate threads for database queries or file read-write operations – because they were I/O operations – we have now manually initiated a thread and used it to handle similar CPU-heavy tasks.

How to Optimize with Multiple Cores

Now that you have a clear understanding of how the process works, let's take it one step further and optimize it using multiple CPU cores.

When you visit the /blocking route, you might notice that it still takes a significant amount of time to respond. This indicates that the optimization isn't fully complete yet. So far, we've used a separate thread meaning we've utilized one CPU core outside the main thread. But most modern machines have multiple cores, and we can take advantage of that to improve performance.

Checking How Many Cores Your System Has

Before assigning multiple cores, you can check how many cores are available on your system:

• macOS (Unix-based):

    sysctl -n hw.ncpu
  

  This command returns the total number of CPU cores on your machine. For example, on my Mac, it shows 10, meaning I have ten cores available.

• Linux:

    nproc
  

  This will print the number of processing units available.

• Windows (Command Prompt):

    echo %NUMBER_OF_PROCESSORS%
  

Each of these commands will help you determine how many cores you can use for parallel processing.

Utilizing Multiple Cores for Faster Execution

Once you know how many cores your machine has, you can decide how many of them to allocate for a specific job. For example, since my system has ten cores, I might choose to use four cores for the task.

By distributing the workload across multiple threads (each running on its own core), you can achieve significant performance improvements. Instead of relying on just one core, the system can execute multiple parts of the task simultaneously reducing the total execution time dramatically.

In short, the more cores you effectively utilize, the faster your computationally heavy tasks can complete (as long as your code is designed to handle parallel execution safely).

How to Implement Multi-Core Optimization

Now, we'll optimize the /blocking task by using multiple worker threads. First, we’ll create copies of our existing files:

• index.js → index-optimized.js

• worker.js → worker-optimized.js

We plan to use four threads. Even though the machine may have more cores, using all could overload the system, so we’ll limit it to four.

index-optimize.js:

// index-optimize.js

const express = require("express");
const { Worker } = require("worker_threads");

const app = express();
const port = process.env.PORT || 3000;
const THREAD_COUNT = 4;

function createWorker() {
    return new Promise((resolve, reject) => {
        const worker = new Worker("./worker-optimized.js", {
            workerData: {
                thread_count: THREAD_COUNT,
            },
        });

        worker.on("message", (data) => {
            resolve(data);
        });

        worker.on("error", (err) => {
            reject(`An Error occured : ${err}`);
        });
    });
}

app.get("/non-blocking", (req, res) => {
    res.status(200).send("This page is non-blocking.");
});

app.get("/blocking", async (req, res) => {
    const workerPromise = [];

    for (let i = 0; i < THREAD_COUNT; i++) {
        workerPromise.push(createWorker());
    }

    const threadResults = await Promise.all(workerPromise);
    const total =
        threadResults[0] +
        threadResults[1] +
        threadResults[2] +
        threadResults[3];

    res.status(200).send(`Result is ${total}`);
});

app.listen(port, () => {
    console.log(`App listening on port ${port}`);
});

Here, we create a createWorker function that returns a Promise. Inside it, the worker is created, and the message and error events are handled. In the /blocking route, we create multiple workers asynchronously, wait for all of them to finish using Promise.all, and then sum the results.

worker-optimize.js:

// worker-optimize.js

const { parentPort, workerData } = require("worker_threads");

let result = 0;
for (let i = 0; i < 10000000000 / workerData.thread_count; i++) {
    result++;
}

parentPort.postMessage(result);

Each worker receives thread_count from the main thread and calculates its part of the task. Once done, it sends the result back using parentPort.postMessage. This way, heavy computation is distributed, and the main thread remains free.

Understanding the Code Line by Line

Alright, some of these concepts might seem a bit complex at first. But don't worry! We we’ll go through all the code line by line, explaining everything in detail so that you understand exactly what is happening and why.

Thread Planning and Configuration

Now, coming to the main point we'll be using threads, right? We've planned to use multiple threads. Let's say we've decided to use four threads. Our machine has ten cores, but we won't use them all because that would consume all our system resources. So, we'll use four threads from four of the available cores.

For this reason, in the index-optimized.js file, we've created a constant to store the number of threads we'll use. Let's say we've set it to 4 here, so that later another developer can easily change it if needed.

The createWorker Function

Then, we've created a new function called createWorker. The purpose of this function is to create a new Worker. Here, we’re returning a promise because the process of creating a Worker is performed asynchronously.

This is because when we create four workers, we want the creation process itself to happen asynchronously, so the main thread doesn't get blocked. After all, creating a worker is essentially a separate process.

The best practice is to create workers asynchronously. That's why we created the createWorker function, which returns a promise. As we know, events are listened to inside a promise, where resolve and reject are used. In the /blocking handler, we can handle the worker's result or any errors through this promise.

Creating a Worker

To create a worker, we use:

const worker = new Worker("./worker-optimized.js");

Here, we need to provide the path to the Worker file. Then, as the second parameter, we can pass some options. For example, if we want to send some data to the Worker, we use { workerData }. Inside this workerData, we'll send the THREAD_COUNT, which is stored in our file as THREAD_COUNT.

For instance, we can pass an object in workerData like:

{
  threadCount: THREAD_COUNT;
}

When this Worker is being created, we send some properties from index-optimized.js as workerData. This is because in worker-optimized.js, the worker can use parentPort to know how many threads it should use. So, we've included a threadCount property in workerData. When the worker starts, it reads threadCount from workerData and works accordingly. This is how we've designed the createWorker function, which simply returns a Promise.

Event Handling and Promise Structure

Here, we made an important change compared to our original index.js file.

Since we copied all the code from index.js into index-optimized.js, we adjusted the /blocking route handler. Specifically, we removed the direct creation of the Worker from the /blocking handler. Instead, the Worker is now created inside the createWorker function.

Also, all the event listeners (message and error) that were previously inside the /blocking handler have also been moved into the createWorker function. This means that the worker is fully managed within the function, and the /blocking handler now only handles the promise results, keeping the main thread clean and organized.

But since these events are being listened to inside a promise, we cannot send the response directly from there. We'll send the response inside the /blocking handler. So from the Promise, we only use resolve and reject.

For example:

resolve(`Result is ${data}`);
reject(`An error occurred ${err}`);

In other words, the entire process of creating a worker has been moved into the createWorker function, which ultimately returns a promise.

Dividing Work Across Multiple Workers

Now, inside the /blocking handler, I simply call the createWorker function. The workerData we provide tells the worker what task it should perform. The created worker is linked with parentPort in the worker-optimized.js file, which essentially communicates with the parent thread.

Now, we want to divide the for-loop running up to one million across four cores. The number of cores to use is sent from index-optimized.js as part of workerData. Because this information is in workerData, the workers can automatically divide and handle the tasks among themselves.

So, in the worker-optimized.js file, we'll get the workerData using:

{ workerData } = require("worker_threads")

Then, in the for-loop condition, we'll use workerData.threadCount. This means the threadCount sent from index-optimized.js will be used here instead of hardcoding 4. This is best practice because the data is passed to the worker at the time of its creation. In worker-optimized.js, we use this to divide the work into four parts. Then, four workers will be created, meaning the createWorker function will be called four times. Each worker will take one part of the work, and at the end, all results will be combined. This is how the entire process is completed.

So, in this /blocking handler, our task is to collect the results of the four promises and then sum them all. Let's say we store them in an array called workerPromises. Each entry in this array will hold the promise result of a worker. Then, by combining all of them, we get the final result.

Since we need to create four Workers, we'll run a for-loop: for (let i = 0; i < THREAD_COUNT; i++). Inside the body of this loop, we'll call the createWorker function each time. This means that in every iteration, a new worker is created, and its promise is pushed into the workerPromises array.

So, inside the body of this loop, we'll call the createWorker function four times. Each call to createWorker returns a promise. These four promises are pushed into the workerPromises array, like workerPromises.push(createWorker()). This way, each worker has its own promise. In the end, since all the promises are stored in the workerPromises array, we can easily call Promise.all(workerPromises).

So, we used threadResults = await Promise.all(workerPromises). As we know, Promise.all can handle multiple Promises together. Here, we passed the workerPromises array, so threadResults will contain the results of the four promises as separate elements, like threadResults[0], threadResults[1], threadResults[2], and threadResults[3]. Then, we sum these results to get the total calculation, meaning threadResults[0] + threadResults[1] + threadResults[2] + threadResults[3] gives the final result. Since we used await, the entire function needs to be async.

Once everything is done correctly, we can send this total result to the client using res.status(200).send(Result is ${total}). This way, the total calculation works correctly, unlike before.

So, I hope it's clear now: we called the createWorker function four times here. Each call returns a promise. We then awaited all these promises together using Promise.all, so all the results came in at once. After that, we summed these results. The /blocking handler is essentially the one executing our operational work.

Handling Complex Tasks

So, in the worker-optimized.js file, we've essentially divided the work into four parts. But it's not necessary that the task will always be a for-loop. There could be different types of complex tasks as well, like image processing, data processing, or pagination.

In such cases, we can't always follow the same pattern. So, we need to send the necessary data from index-optimized.js as workerData, and the worker will use that data to perform the task in a separate process.

In the previous example, all the steps were sequential, so simply summing the results gave us the total. But in the case of complex tasks, we need to use data-driven processing.

In other complex applications, you might need to perform different tasks. But the main concept is clear: any data or property we send from here will be received by the worker, which will then divide the work. Each worker – whether you use four, five, or six – will handle its part, and all the results will need to be accumulated. This is essentially the entire process.

Performance Comparison

When working with CPU-intensive tasks in Node.js, dividing the work using worker threads can significantly improve performance. Let's compare the behavior of our application before and after optimization.

Testing Results

Running the index.js file and hitting the /blocking route in the browser takes a significant amount of time.

Running the index-optimized.js file and hitting the same route takes considerably less time – around 3 seconds.

Stopping it and running index.js again clearly shows the original implementation is slower.

Performance Metrics

Key Takeaways

This comparison demonstrates how dividing the work into multiple parts using worker threads can make CPU-intensive tasks far more efficient, keeping the main thread responsive and improving overall performance.

Summary

So, first we saw in index.js how a blocking task can be handled in a non-blocking, asynchronous way. That is, we ran a worker thread, and because of this worker thread, the main thread didn't get blocked, allowing other users to continue their tasks simultaneously.

The Multi-Core Challenge

But the problem is, when we use a new thread on the server, there isn't just a single core. Usually, there are multiple cores, like 8, 16, or more. To use multiple cores, we first need to find out how many cores are available on the server.

Discovering Available Cores

If the server is Linux, we can easily find out the total number of cores using the nproc command. Then we can decide how many cores to use. For example, let's say we decide to use three cores. In index-optimized.js, we've implemented a way to divide the work among these cores.

Asynchronous Worker Creation

So, what we did was wrap the worker creation process in a promise. Since creating a worker takes some time and spinning it up isn't instantaneous, this process is done asynchronously. This way, even if multiple users hit the endpoint to create Workers, the main thread won't be blocked.

How to Implement Multi-Core Optimization

We simply created workers, and then using the createWorker function inside a loop, we spawned four or a specified number of Workers based on the thread count. Each worker posts messages independently, and through the listener, we receive data from each worker. These results are collected via promises, stored together in an array, and finally, we sum all the results from this array to get the final outcome.

So, the other concepts are all part of basic JavaScript. I hope you now understand how worker threads work and how we can use multi-threaded processes in Node.js. It's an excellent concept and a great opportunity to learn thoroughly.

What We Learned

Worker Threads in Node.js provide a powerful way to handle CPU-intensive tasks without blocking the main event loop. By leveraging multiple cores and distributing work across threads, we can significantly improve application performance while maintaining responsiveness for other users.

• Non-blocking execution: Worker threads prevent the main thread from being blocked

• Multi-core utilization: We can leverage multiple CPU cores for parallel processing

• Asynchronous worker creation: Using promises to handle worker creation without blocking

• Result aggregation: Collecting and combining results from multiple workers

• Performance optimization: Distributing heavy computations across multiple threads

This approach is particularly valuable for applications that need to handle computationally intensive tasks while remaining responsive to user requests.

Final Words

If you found the information here valuable, feel free to share it with others who might benefit from it. I’d really appreciate your thoughts – mention me on X @sumit_analyzen or on Facebook @sumit.analyzen, watch my coding tutorials, visit my website or simply connect with me on LinkedIn.

Additional Resources

You can also check the Node.js Worker Threads documentation for more in-depth learning. You can find all the source code from this tutorial in this GitHub repository. If it helped you in any way, consider giving it a star to show your support!

We just published a course on the freeCodeCamp.org YouTube channel that will teach you all about multithreading in Java. This comprehensive course covers everything from the basics to advanced topics, providing both theoretical knowledge and practical code examples. While the primary focus is on Java, the principles and techniques discussed are applicable to other programming languages as well. Ramendu created this course.

Why Learn Multithreading?

Multithreading is fundamental to creating high-performance applications. With the rise of multi-core processors, leveraging multiple threads has become essential to fully utilize the capabilities of modern hardware. Applications that perform CPU-intensive tasks, such as data processing, simulations, and complex calculations, can see large performance improvements when implemented with multithreading. Additionally, multithreading is important for creating responsive user interfaces in applications where long-running tasks are offloaded to separate threads, preventing the UI from freezing and ensuring a smooth user experience.

Learning multithreading not only enhances your programming skills but also opens up numerous career opportunities. Many high-demand fields, including game development, finance, and big data, require a solid understanding of concurrent programming.

Course Content Overview

The course begins with an introduction to the instructor and an overview of what you can expect to learn. You'll start with the basics, such as understanding what multithreading is and how it differs from sequential execution. From there, you'll learn how to create threads using both the Runnable interface and the Thread class, and explore the differences between these two approaches.

As you progress, the course teaches more complex topics such as the join method, daemon threads, and thread priority. You'll learn about synchronized blocks and the potential problems they can cause, as well as how to use the wait and notify methods for inter-thread communication. The producer-consumer problem is also covered, providing a practical example of these concepts in action.

The course also introduces the ExecutorService framework, which simplifies thread management by providing a pool of reusable threads. You'll explore different types of executors, including single-thread, fixed-thread, cached-thread, and scheduled-thread pools, and learn how to choose the ideal pool size for your needs. Advanced concepts such as Callable and Future, synchronized collections, and various concurrency utilities like CountdownLatch, BlockingQueue, ConcurrentMap, CyclicBarrier, and Exchanger are also covered.

Towards the end of the course, you'll learn about the importance of locks and how to use different types of locks such as reentrant locks and read-write locks. The visibility problem in Java, deadlocks, atomic variables, semaphores, and mutexes are discussed to provide a thorough understanding of these critical issues. Finally, the course covers the ForkJoinPool, an advanced framework for parallel execution, before concluding with a summary and a thank-you message.

This course is perfect for anyone looking to master multithreading in Java, from beginners to experienced developers seeking to deepen their understanding. Watch the full course on the freeCodeCamp.org YouTube channel (6-hour watch).

Multithreading is a method of achieving concurrency. It uses the concept of threads – lightweight processes – to execute multiple tasks in parallel. A very popular application of multithreading is the producer-consumer problem.

In this tutorial, we are going to understand what the producer-consumer problem is and touch upon threads and multithreading briefly. Then, we are going to understand how to solve the producer-consumer problem in Java using threads.

Now, I assume you have a basic knowledge of Java. If not, then check out the following resources.

• Free Java Courses for Beginners

• Basics of Java Programming

Table of Contents

• What is the Producer-Consumer Problem?

• Solution using Producer and Consumer Threads and Issue with Synchronization

• Introducing Synchronization in the Message Queue Class

• Producer with Multiple Consumers

• Solution using Java Concurrency's BlockingQueue Class

What is the Producer-Consumer Problem?

The producer-consumer problem is a synchronization problem between different processes. There are three entities in this problem: a producer, a consumer, and a memory buffer. Both the producer and consumer share the same memory buffer.

The producer produces some items and pushes them into the memory buffer. A consumer then consumes these items by popping them out of the buffer. If the buffer is empty, then the consumer waits for the producer to push an item, which it consumes after the producer pushes it.

The memory buffer is of fixed size. If it is full, the producer waits for the consumer to consume an item before pushing a new one. The producer and consumer cannot access the buffer at the same time – that is, it's mutually exclusive. Each process should wait for the other to finish its work on the buffer before it can access the buffer.

Operating systems often encounter this problem where multiple processes access the same memory space to perform their tasks.

We will solve this problem using multithreading, so I assume you have a basic idea about what multithreading is and how it works. If not, then you can read through this tutorial.

We'll start with an attempt to solve it simply using threads and a separate class for message queue. Then, we'll understand its issues and how to overcome them in the next approach. We'll also see other approaches to the problem. Make sure to stick around until the end.

Solution using Producer and Consumer Threads

Let's go over our requirements first.

• Producer and Consumer tasks run in separate threads

• Common data bus, typically a message queue, used by both producer and consumer.

• If not full, producer pushes data into queue, or waits for it to be consumed

• If not empty, consumer takes data out of the queue, or waits for producer to publish.

These are the things we need to implement to solve this problem. Let's create the message queue first.

Message Queue

To set up a message queue, we'll use a class that contains the queue and methods to publish and consume messages.

class Data { 
    Queue<String> q; 
    int capacity; 

    Data(int cap) { 
        q = new LinkedList<>(); 
        capacity=cap; 
    } 
    // other methods 
}

Here, we have used Java's Queue class to store our messages. Each message is of type String. But in bigger applications, the message or payload could be of any object type. We also define the capacity of the message queue.

Next, we'll implement the publish() method. The method accepts a new message to be published.

public void publish(String msg) { // publish message to the queue }

First, we check if the queue is full. We can't publish a new message if the queue has reached capacity.

if(q.size() == capacity){ 
    return; 
}

If the queue is not full, then add the message to the queue.

q.add(msg);

We'll add print statements to understand the workflow better.

public void publish(String msg) { 
    String name=Thread.currentThread().getName(); 
    if(q.size() == capacity){ 
        System.out.println("Queue Full!"+name+" waiting for message to be consumed..."); 
        return; 
    } 
    q.add(msg); 
    System.out.println("Message published:: "+msg); 
    System.out.println("Queue: "+ q); 
    System.out.println(); 
}

Here, we just print the thread that is inside the method, the message published, and the resulting queue.

Let's implement the consume() method now. This method does not take any arguments and works similarly to the publish() method. We first check if the queue is empty, before removing anything from the queue.

if(q.size()==0){ 
    return; 
}

Then, we remove the message.

q.poll();

Again, we'll add print statements to understand the workflow better.

public void consume()  { 
    String name=Thread.currentThread().getName(); 
    if(q.size()==0){ 
        System.out.println(name+" waiting for new message..."); 
        return; 
    } 
    String msg = q.poll(); 
    System.out.println(name+" has consumed msg:: "+msg); 
    System.out.println("Queue: "+ q); 
    System.out.println(); 
}

Producer Thread

Let's write the producer logic now. We'll create a class Producer that will run in a thread. There are several ways to create threads in Java. We'll use the Runnable interface to create our thread since it's the most preferred approach.

class Producer implements Runnable{ 
    Data data; 
    public Producer(Data data) { 
        this.data = data; 
    } 

    @Override public void run() { } 
}

The producer has access to the data bus object which is passed to it via the constructor. The producer logic goes inside the run() method. By overriding the run method, you are writing functionality that runs in a thread.

Now, a producer's ways of producing and publishing data differs in every application. For this post, we are going to simulate a functionality where the producer keeps publishing messages every few seconds.

We'll define a list of messages that the producer can use.

final String[] messages={"Hi!!", "How are you!!", "I love you!", "What's going on?!!", "That's really funny!!"};

Here's the producer logic inside the run() method:

public void run() { 
    int i=0; 
    try { 
        while(true){ 
            Thread.sleep(1000); 
            data.publish(messages[i]); 
            i=(i+1)%messages.length; 
        } 
    } catch (InterruptedException e) {} 
}

In this code, the producer is publishing a message from the messages list every 1000 ms. Thread.sleep(_some_delay_) pauses execution of the thread for a certain period. Since it throws an exception, we surround the code with a try-catch block.

This is just for demonstration purposes – don't worry about the logic. Our implementation works regardless of the producer or consumer logic.

Consumer Thread

Similar to producer thread, let's simulate the consumer logic.

class Consumer implements Runnable{ 
    Data data; 
    public Consumer(Data data) { 
        this.data = data; 
    } 
    @Override public void run() { 
        try { 
            while(true){ 
                Thread.sleep(2000); 
                data.consume(); 
            } 
        } catch (InterruptedException e) {} 
    } 
}

Here, the consumer tries to consume a message every 2000 ms.

Putting it all Together

Now, we have our message queue along with the producer and consumer classes. Let's create one producer and one consumer thread and start them.

We'll create a Data object with capacity of 5 messages and create our producer and consumer threads with the objects of the Producer and Consumer classes.

public class Main { 
    public static void main(String[] args) { 
        Data data = new Data(5); 
        Thread producer=new Thread(new Producer(data), "producer"); 
        Thread consumer=new Thread(new Consumer(data), "consumer");
        producer.start(); 
        consumer.start(); 
    } 
}

The run() method executes in a separate thread when start() is called.

Output:

Inconsistent output

Here, the output is inconsistent with the desired workflow. Even after publishing the first message, the consumer is still waiting. Then, a consumer has consumed a message Hi!! that doesn't exist. The state of the queue is also inconsistent.

You will probably get a different output, since thread execution depends on the core OS. But the issue still persists. Why does this happen?

Synchronization Issue With the Data Class

Both producer and consumer threads run simultaneously, working on the same resource. They are accessing the message queue at the exact same time. Both the threads may start with one version of the resource and by the time they perform an operation, they are working on a different version.

This leads to a race condition. Both threads end up competing for the same resource and give inconsistent results. The producer thread is trying to add a message to the queue, while at the same time a consumer is trying to consume a message. There's no way of controlling which message the consumer could get.

To solve this issue, we need some kind of mechanism to ensure that only one thread can operate on a shared resource at a time. In this case, we'll use the concept of synchronization.

At a glance, a synchronized function or a block can only be executed by one thread at a time. A thread entering such a block acquires a "lock" on the object and any other threads have to wait until the thread releases this lock – that is, until it finishes working on the shared resource.

We'll use a similar method to solve our issue.

Introducing Synchronization in the Message Queue

To ensure the message queue is only accessed by one thread (producer or consumer) at a time, a thread needs to secure a lock on the Data object before performing any operations.

How to Use the synchronized Keyword

An object can be made mutually exclusive by using the synchronized keyword. We'll use the synchronized keyword with the publish() and consume() methods.

public synchronized void publish(String msg)

public synchronized void consume()

Now, a thread needs to acquire a lock on the object before entering these methods.

What are the wait() and notify() Methods?

We have achieved synchronization – only one thread can access a shared resource at a time to ensure consistency. Now, we need to establish communication between the producer and consumer threads.

Let's understand what we need first. If the queue is full, the producer needs to wait for a consumer to consume an item. Similarly, if the queue is empty, the consumer needs to wait until the producer pushes an item.

Also, when a producer pushes an item, it needs to notify all the waiting consumer threads about the action. The is also true when the consumer consumes an item. So, how do we establish this communication?

We can do this using the wait() and notify() methods. When the wait() method is called, the thread releases the lock on the object and enters a waiting state until another thread calls the notify() or notifyAll() method.

notify() wakes up one thread that is in the waiting state, while notifyAll() wakes up all waiting threads. When a thread wakes up again, it has to re-acquire the lock on the object. If another thread has the lock, then this thread needs to wait until the other thread releases the lock.

You can learn more about the wait() and notify() methods here.

How to Communicate Between Threads using wait() and notify()

Let's use the above methods. A producer needs to wait before it pushes an item if the queue is full. So, invoke the wait() method if the queue is at capacity. Similarly, the consumer needs to wait if the queue is empty.

To wake up threads from the waiting state, call notifyAll() after the producer publishes a message and the consumer consumer a message. This will notify all the waiting threads.

Here is the updated publish() method:

public synchronized void publish(String msg) throws InterruptedException { 
    String name=Thread.currentThread().getName(); 
    if(q.size() == capacity){ 
        System.out.println("Queue Full!"+name+" waiting for message to be consumed..."); 
        wait(); 
    } 
    q.add(msg); 
    System.out.println("Message published:: "+msg); 
    System.out.println("Queue: "+ q); 
    System.out.println(); 
    notifyAll(); 
}

And here's the updated consume() method:

public synchronized void consume() throws InterruptedException { 
    String name=Thread.currentThread().getName(); 
    if(q.size()==0){ 
        System.out.println(name+" waiting for new message..."); 
        wait(); 
     } 
    String msg = q.poll(); 
    System.out.println(name+" has consumed msg:: "+msg);
    System.out.println("Queue: "+ q); 
    System.out.println(); 
    notifyAll(); 
}

wait() and notify() can throw InterruptedException, so we add a throws declaration to the methods.

Output:

Output with Synchronization‌

This time, the output is more consistent and we are getting the expected behavior. The producer keeps publishing messages and the consumer consumes those messages.

Producer waiting

Here, the queue is full and the producer waits for the consumer to consume a message. Only after that does the producer publish a new message.

Producer with Multiple Consumers

So far, we have tackled the problem with one producer and one consumer. In a real-world application, there could be multiple producers and consumers, all of them running in separate threads.

Let's add more consumer threads to see how we could handle this scenario:

for(int i=1;i<=5;i++){ 
    new Thread(new Consumer(data), "Consumer "+i).start();
}

Here, we have created 5 consumer threads, labelled them, and started them one by one. But, this is not enough. There is an issue with the existing approach.

Let's reduce the consumer sleep time and run the code:

Thread.sleep(500);

Multiple consumers issue

Here, after consumer 5 has consumed a message, the other consumers are able to consume even if the queue is empty.

The issue lies in the following condition:

if(q.size()==0){
    wait();
}

Let's understand the workflow first. Consider Consumer 5 (C5) and Consumer 1 (C1). C5 secures the lock on the method and enters it. The queue is initially empty, so it releases the lock and waits for the producer. At the same time, C1 secures the lock and enters the method. It also waits for the producer.

So, C5 and C1 are waiting. The producer publishes a message. C5 and C1 are notified and they wake up. C5 reacquires the lock and proceeds to consume the message, while C1 waits for C5 to release the lock. Here, C1 is not waiting because of wait() – it has woken up and now it's waiting at the next line.

After C5 consumes the message and releases the lock, C1 continues and tries to consume the message. But the queue is empty now, so it receives null or throws an exception. This also happens with the other threads.

To prevent this, we need to check if the queue is empty once again. So, instead of using an if condition, we use a while loop like this:

while(q.size()==0){
            wait();
        }

This checks if the queue is empty every time a thread wakes up. So, if multiple threads wake up at the same time, it should check if another thread has emptied the queue.

We do the same for checking if the queue is full.

while(q.size() == capacity){
            wait();
        }

This time, the code runs without any issues.

Multiple consumers correct output

Here is the complete code for Data class:

class Data {
    Queue<String> q;
    int capacity;
    Data(int cap) {
        q = new LinkedList<>();
        capacity=cap;
    }

    public synchronized void publish(String msg) throws InterruptedException {
        String name=Thread.currentThread().getName();
        while(q.size() == capacity){
            System.out.println("Queue Full!"+name+" waiting for message to be consumed...");
            wait();
        }
        q.add(msg);
        System.out.println("Message published:: "+msg);
        System.out.println("Queue: "+ q);
        System.out.println();
        notifyAll(); 
    }

    public synchronized void consume() throws InterruptedException {
        String name=Thread.currentThread().getName();
        while(q.size()==0){
            System.out.println(name+" waiting for new message...");
            wait();
        }
        String msg = q.poll();
        System.out.println(name+" has consumed msg:: "+msg);
        System.out.println("Queue: "+ q);
        System.out.println();
        notifyAll();
    }
}

You can create any number of producers and consumers and test this code in multiple scenarios.

Solution using Java Concurrency's BlockingQueue Class

So far you have learned what the producer-consumer problem is and how it can be solved. But, while working on real-time applications, we probably won't implement synchronization manually.

Instead, we can use the BlockingQueue class from java.util.concurrent package. The difference between Queue and BlockingQueue is that it waits for the queue to become non-empty before a message can be consumed. Similarly, it waits for the queue to have space before publishing a new message.

We can initialize the blocking queue in the following way:

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

This creates a blocking queue of capacity 10. To publish an item, we use the put() method, and to remove an item, we use the take() method.

Let's first use this in our Producer class:

class Producer implements Runnable{
    BlockingQueue<String> q;
    final String[] messages={"Hi!!", "How are you!!", "I love you!", "What's going on?!!", "That's really funny!!"};
    public Producer(BlockingQueue<String> q) {
        this.q = q;
    }

    @Override
    public void run() {
        int i=0;
        try {
            while(true){
                Thread.sleep(500);

                q.put(messages[i]);

                System.out.println("Message published:: "+messages[i]);
                i=(i+1)%messages.length;
            }
        } catch (InterruptedException e) {}
    }

}

Here, we are not using a separate Data class with synchronized methods, since the put() and take() methods of BlockingQueue are synchronized. Here, if the queue is full, the put() method waits for a consumer to consume a message.

Similarly, let's update our Consumer class:

class Consumer implements Runnable{
    BlockingQueue<String> q;

    public Consumer(BlockingQueue<String> q) {
        this.q = q;
    }

    @Override
    public void run() {
        try {
            while(true){
                Thread.sleep(1500);

                String msg=q.take();

                String name=Thread.currentThread().getName();
                System.out.println(name+" has consumed msg:: "+msg);
            }
        } catch (InterruptedException e) {}
    }    
}

Here, if the queue is empty, the take() method waits for the producer to publish a message.

Let's create our BlockingQueue object and start these threads:

public class Main {
    public static void main(String[] args) {
        BlockingQueue<String> q = new ArrayBlockingQueue<>(10);
        Thread producer = new Thread(new Producer(q));
        producer.start();
        for(int i=1;i<=5;i++){
            new Thread(new Consumer(q), "Consumer "+i).start();
        }
    }

}

Here, we have one producer thread and 5 consumer threads. Let's see the output:

Output for BlockingQueue implementation

In the output, you can see that after consumers 1, 3, and 2 have consumed a message, the other consumers wait for a message to be published before consuming it.

There could be a few inconsistencies while printing these messages since the thread only stops at the put() or take() methods and not the println() statements. But the code runs properly. Again, the output will be different each time you run the code.

So, while working on big projects, you can use the BlockingQueue class. But it's important to understand how to deal with the whole producer-consumer problem from scratch. This is really helpful, especially during interviews, since you typically won't be allowed to use the BlockingQueue class.

Conclusion

In this tutorial, you learned about an important problem in concurrency, the product-consumer problem. And you learned how you can solve it using multithreading in Java.

In total, we implemented four different approaches:

First, I started out with a very basic and straightforward implementation. Running the producer and consumer in separate threads helped achieve concurrency. But since they used the same message queue, there was a synchronization problem.

Therefore, in the next approach, we added synchronization to fix the issue. Then, we added more consumers who would all wait for the producer. There, we learned why it is important to check the full and empty conditions every time a thread wakes up.

After going through the whole implementation from scratch, we saw a simple way to solve the Producer-Consumer problem in Java using BlockingQueue. By understanding different approaches and their issues, you can get a better idea of how to tackle a problem. I hope this guide helps with your future endeavors.

If you are unable to understand the content or find the explanation unsatisfactory, let me know. New ideas are always appreciated! Feel free to connect with me on Twitter. Till then, goodbye!

Threads in Java are pre-defined classes that are available in the java.package when you write your programs. Generally, every program has one thread which is provided from the java.package.

All of these threads use the same memory, but they are independent. This means that any exception in a thread will not affect how other threads work, despite them sharing the same memory.

What You'll Learn:

• In this article we will learn about how to create a thread
• We will learn about the concept of multi tasking.
• We will learn about the lifecycle of threads and also about the thread class.

What are Threads in Java?

Threads allow us to do things more quickly in Java. That is, they help us perform multiple things all at once.

You use threads to perform complex operations without any disturbance in the main program.

When various multiple threads are executed at the same time, this process is known as multi-threading.

Multi-threading is mainly used in gaming and similar programs. Since we now know a bit about multi-threading, let's also learn about the concept of multi-tasking.

What is Multitasking in Java?

Multitasking is the process that lets users perform multiples tasks at the same time. There are two ways to enable multitasking in Java:

1. Process-based multitasking: The processes in this type of multitasking are heavy and a lot of time is consumed. This is because the program takes a long time to switch between different processes.
2. Thread-based multi tasking: Threads are light-weight compared to process-based multi tasking, and the time taken to switch between them is shorter.

Now let's learn about the working model of a thread.

Thread Lifecycle in Java

What is a thread lifecycle in Java?

In Java, a thread will always remain in one of a few different states (which we will read about below).

The thread goes through various stages in its lifecycle. For example a thread is first born, then it gets started, and goes through these various stages until it dies.

The thread model consists of various states. Let's learn about each of them in more detail:

1. New: the model is in the new state when the code is not yet running.
2. Running state or the active stage: this is the state when the program is under execution or is ready to execute.
3. Suspended state: you can use this state if you want to pause activity when something specific happens (and lets you temporarily stop execution).
4. Blocked state: a thread is under the blocked state when it's waiting for resources. In the blocked state, the thread scheduler clears the queue by rejecting unwanted threads which are present.
5. Terminated state: this state stops a thread's execution immediately. A terminated thread means that it is dead and is no longer available for use.

Thread Methods

What are thread methods in Java?

Thread methods in Java are very important while you're working with a multi-threaded application. The thread class has some important methods which are described by the thread itself.

Now let's learn about each of these methods:

1. public void start(): you use this method to start the thread in a separate path of execution. Then it invokes the run() method on the thread object.
2. public void run(): this method is the starting point of the thread. The execution of the thread begins from this process.
3. public final void setName(): this method changes the name of the thread object. There is also a getName() method for retrieving the name of the current context.
4. public final void setPriority(): you use this method to set the values of the thread object.
5. public void sleep(): you use this method to suspend the thread for a particular amount of time.
6. public void interrupt(): you use this method to interrupt a particular thread. It also causes it to continue execution if it was blocked for any reason.
7. public final boolean isAlive(): this method returns true if the thread is alive.

Now let's learn about creating a thread.

How to Create a Thread in Java

There are two ways to create a thread:

First, you can create a thread using the thread class (extend syntax). This provides you with constructors and methods for creating and operating on threads.

The thread class extends the object class and implements a runnable interface. The thread class in Java is the main class on which Java’s multithreading system is based.

Second, you can create a thread using a runnable interface. You can use this method when you know that the class with the instance is intended to be executed by the thread itself.

The runnable interface is an interface in Java which is used to execute concurrent thread. The runnable interface has only one method which is run().

Now let's see the syntax of both of them:

How to use the extend syntax:

public class Main extends thread {
  public void test() {
    System.out.println("Threads are very helpful in java");
  }
}

Here's an example of the extend method:

public class Main extends test {
  public static void main(String[] args) {
    Main test = new Main();
    test.start();
    System.out.println("Threads are very much helpful in java");
  }
  public void run() {
    System.out.println("Threads are very helpful in java");
  }
}

Using the syntax of the extended class we have just implemented it in this example. Run the above code in your editor to see how it works.

How to use a runnable interface:

public class Main implements runnable {
  public void test() {
    System.out.println("Threads are very helpful in java");
  }
}

And here's an example of using a runnable interface:

public class cal implements test {
  public static void main(String[] args) {
    cal obj = new cal();
    Thread thread = new Thread(obj);
    thread.start();
    System.out.println("Threads are very much helpful in java");
  }
  public void run() {
    System.out.println("Threads are very much helpful in java");
  }
}

Since we extended the thread class, our class object will not be treated as a thread object. Run the above code in your compiler to see how it works.

How to Implement Threads in Java – Examples

Let's see few more examples of implementing threads in Java:

class First
{
public static void main (String [ ]args) throws IOException
{
Thread t =Thread.currentThread( );
System.out.println(“CURRENTTHREAD = ” + t);
t.setName(“NewThread”);
t.setPriority(t.getPriority( ) – 1);
System.out.println(“CURRENTTHREAD = ” + t);
System.out.println(“NAME = ” + t.getName( ));
}
}

Output

CURRENTTHREAD =THREAD [main, 5, main]
CURRENTTHREAD =THREAD [New Thread, 4, main]
NAME = New Thread

Here we have created a thread then printed the current thread. Then we have set the name of the thread as a new thread and finally we have printed the name of the thread. Run the above code in your editor to see how it works.

Here's another example:

class First implements Runnable
{
Thread t;
First( ){
t = new Thread(this,"NEW");
System.out.println(“CHILD :” + t);
t.start();
}
public void run( ) {
try{ for(int i = 5; i>0, i- -) {
System.out.println("CHILD :" + i);
Thread.sleep(500); }
} //END OFTRY BLOCK
catch(InterruptedException e){ }
System.out.println("EXITING CHILD");
} }
class Second
{
public static void main(String [ ]args) throws IOException
{
new First();
try{
for(int i = 5; i>0, i- -)
{
System.out.println("MAIN :"  + i);
Thread.sleep(1000);
}
} //END OFTRY BLOCK
catch(InterruptedException e){ }
System.out.println("Exiting man");
}
}

Output

CHILD = THREAD [NEW, 5, main]
MAIN : 5
CHILD : 5
CHILD : 4
MAIN : 4
CHILD : 3
CHILD : 2
MAIN : 3
CHILD : 1
EXITING CHILD
MAIN : 2
MAIN : 1
EXITING MAIN

Here we have created a thread and then printed the child thread. Then we ran the for loop inside the run function and printed the child. Run the code in your editor to see how it works.

Now let's learn more about multi threading.

Multi-Threading in Java

As I briefly explained above, multithreading in Java refers to the execution of several threads at the same time.

Multithreading is useful because threads are independent – and in multithreading we can perform the execution of several threads at the same time without blocking the user.

It also helps us save time as we can perform several operation at the same time. A good real time example of multi threading in Java is word processing. This program checks the spelling of what we're typing while we write a document. In this case each task will be provided by a different thread.

Use cases of multi-threading in Java

Now that you know how multi-threading saves time by allowing you to perform multiple operation together, let's learn about some practical uses cases of multi-threading:

1. Word processing, which we discussed above.
2. Gaming.
3. Improving the responsiveness of a server.
4. Using thread synchronization functions to provide enhanced processes to process communication.

Now let's look at an example program to learn how to implement multithreading:

class First implements Runnable
{
Thread t; String S;
First(String Name){
S=Name;
t = new Thread(this,S);
System.out.println("CHILD :" + t);
t.start();
}
public void run( ) {
try{ for(int i = 5; i>0, i- -) {
System.out.println(S + " :" + i);
Thread.sleep(1000); }
} //END OF TRY BLOCK
catch(InterruptedException e){ }
System.out.println("EXITING " + S);
} 
}
class Second
{
public static void main(String [ ]args) throws IOException
{
new First("ONE");
new First("TWO");
new First("THREE");
try{
Thread.sleep(20000);
} //END OFTRY BLOCK
catch(InterruptedException e){ }
System.out.println("EXITING MAIN");

Output

CHILD =THREAD [ONE, 5, main]
CHILD =THREAD [TWO, 5, main]
CHILD =THREAD [THREE, 5, main]
ONE : 5 ONE : 2
TWO : 5 TWO : 2
THREE : 5 THREE:2
ONE : 4 ONE : 1
TWO : 4 TWO : 1
THREE : 4 THREE : 1
ONE : 3 EXITING ONE
TWO : 3 EXITINGTWO
THREE : 3 EXITINGTHREE
EXITING MAIN

In the code above, we have implemented multi-threading by using the run method. Then we have initiated a thread by using the constructor, since the thread is created from it. Then we can start by calling the start() method. Run the code in your editor to see how it works.

Conclusion

A thread is a light-weight process in Java. It's a path of execution within a process. There are only two methods to create threads in Java.

In a browser, multiple tabs can be multiple threads. Once a thread is created it can be present in any of the states we discussed above.

Thank you for reading.

I recently developed a project that I called Hydra: a multithreaded link checker written in Python. Unlike many Python site crawlers I found while researching, Hydra uses only standard libraries, with no external dependencies like BeautifulSoup. It’s intended to be run as part of a CI/CD process, so part of its success depended on being fast.

Multiple threads in Python is a bit of a bitey subject (not sorry) in that the Python interpreter doesn’t actually let multiple threads execute at the same time.

Python’s Global Interpreter Lock, or GIL, prevents multiple threads from executing Python bytecodes at once. Each thread that wants to execute must first wait for the GIL to be released by the currently executing thread. The GIL is pretty much the microphone in a low-budget conference panel, except where no one gets to shout.

This has the advantage of preventing race conditions. It does, however, lack the performance advantages afforded by running multiple tasks in parallel. (If you’d like a refresher on concurrency, parallelism, and multithreading, see Concurrency, parallelism, and the many threads of Santa Claus.)

While I prefer Go for its convenient first-class primitives that support concurrency (see Goroutines), this project’s recipients were more comfortable with Python. I took it as an opportunity to test and explore!

Simultaneously performing multiple tasks in Python isn’t impossible; it just takes a little extra work. For Hydra, the main advantage is in overcoming the input/output (I/O) bottleneck.

In order to get web pages to check, Hydra needs to go out to the Internet and fetch them. When compared to tasks that are performed by the CPU alone, going out over the network is comparatively slower. How slow?

Here are approximate timings for tasks performed on a typical PC:

Peter Norvig first published these numbers some years ago in Teach Yourself Programming in Ten Years. Since computers and their components change year over year, the exact numbers shown above aren’t the point. What these numbers help to illustrate is the difference, in orders of magnitude, between operations.

Compare the difference between fetching from main memory and sending a simple packet over the Internet. While both these operations occur in less than the blink of an eye (literally) from a human perspective, you can see that sending a simple packet over the Internet is over a million times slower than fetching from RAM. It’s a difference that, in a single-thread program, can quickly accumulate to form troublesome bottlenecks.

In Hydra, the task of parsing response data and assembling results into a report is relatively fast, since it all happens on the CPU. The slowest portion of the program’s execution, by over six orders of magnitude, is network latency. Not only does Hydra need to fetch packets, but whole web pages!

One way of improving Hydra’s performance is to find a way for the page fetching tasks to execute without blocking the main thread.

Python has a couple options for doing tasks in parallel: multiple processes, or multiple threads. These methods allow you to circumvent the GIL and speed up execution in a couple different ways.

Multiple processes

To execute parallel tasks using multiple processes, you can use Python’s ProcessPoolExecutor. A concrete subclass of Executor from the concurrent.futures module, ProcessPoolExecutor uses a pool of processes spawned with the multiprocessing module to avoid the GIL.

This option uses worker subprocesses that maximally default to the number of processors on the machine. The multiprocessing module allows you to maximally parallelize function execution across processes, which can really speed up compute-bound (or CPU-bound) tasks.

Since the main bottleneck for Hydra is I/O and not the processing to be done by the CPU, I’m better served by using multiple threads.

Multiple threads

Fittingly named, Python’s ThreadPoolExecutor uses a pool of threads to execute asynchronous tasks. Also a subclass of Executor, it uses a defined number of maximum worker threads (at least five by default, according to the formula min(32, os.cpu_count() + 4)) and reuses idle threads before starting new ones, making it pretty efficient.

Here is a snippet of Hydra with comments showing how Hydra uses ThreadPoolExecutor to achieve parallel multithreaded bliss:

# Create the Checker class
class Checker:
    # Queue of links to be checked
    TO_PROCESS = Queue()
    # Maximum workers to run
    THREADS = 100
    # Maximum seconds to wait for HTTP response
    TIMEOUT = 60

    def __init__(self, url):
        ...
        # Create the thread pool
        self.pool = futures.ThreadPoolExecutor(max_workers=self.THREADS)


def run(self):
    # Run until the TO_PROCESS queue is empty
    while True:
        try:
            target_url = self.TO_PROCESS.get(block=True, timeout=2)
            # If we haven't already checked this link
            if target_url["url"] not in self.visited:
                # Mark it as visited
                self.visited.add(target_url["url"])
                # Submit the link to the pool
                job = self.pool.submit(self.load_url, target_url, self.TIMEOUT)
                job.add_done_callback(self.handle_future)
        except Empty:
            return
        except Exception as e:
            print(e)

You can view the full code in Hydra’s GitHub repository.

Single thread to multithread

If you’d like to see the full effect, I compared the run times for checking my website between a prototype single-thread program, and the multiheaded - I mean multithreaded - Hydra.

time python3 slow-link-check.py https://victoria.dev

real    17m34.084s
user    11m40.761s
sys     0m5.436s


time python3 hydra.py https://victoria.dev

real    0m15.729s
user    0m11.071s
sys     0m2.526s

The single-thread program, which blocks on I/O, ran in about seventeen minutes. When I first ran the multithreaded version, it finished in 1m13.358s - after some profiling and tuning, it took a little under sixteen seconds.

Again, the exact times don’t mean all that much; they’ll vary depending on factors such as the size of the site being crawled, your network speed, and your program’s balance between the overhead of thread management and the benefits of parallelism.

The more important thing, and the result I’ll take any day, is a program that runs some orders of magnitude faster.

There are 7,713,468,100 people in the world in 2019, around 26.3% of which are under 15 years old. This works out to 2,028,642,110 children (persons under 15 years of age) in the world this year.

Santa doesn’t seem to visit children of every religion, so we’ll generalize and only include Christians and non-religious folks. Collectively that makes up approximately 44.72% of the population. If we assume that all kids take after their parents, then 907,208,751.6 children would appear to be Santa-eligible.

What percentage of those children are good? It’s impossible to know; however, we can work on a few assumptions. One is that Santa Claus functions more on optimism than economics and would likely have prepared for the possibility that every child is a good child in any given year. Thus, he would be prepared to give a toy to every child. Let’s assume it’s been a great year and that all 907,208,751.6 children are getting toys.

That’s a lot of presents, and, as we know, they’re all made by Santa’s elves at his North China Pole workshop. Given that there are 365 days in a year and one of them is Christmas, let’s assume that Santa’s elves collectively have 364 days to create and gift wrap 907,208,752 (rounded up) presents. That works out to 2,492,331.74 presents per day.

Almost two-and-a-half million presents per day is a heavy workload for any workshop. Let’s look at two paradigms that Santa might employ to hit this goal: concurrency, and parallelism.

A sequential process

Suppose that Santa’s workshop is staffed by exactly one, very hard working, very tired elf. The production of one present involves four steps:

1. Cutting wood
2. Assembly and gluing
3. Painting
4. Gift-wrapping

With a single elf, only one step for one present can be happening at any instance in time. If the elf were to produce one present at a time from beginning to end, that process would be executed sequentially. It’s not the most efficient method for producing two-and-a-half million presents per day; for instance, the elf would have to wait around doing nothing while the glue on the present was drying before moving on to the next step.

Concurrency

In order to be more efficient, the elf works on all presents concurrently.

Instead of completing one present at a time, the elf first cuts all the wood for all the toys, one by one. When everything is cut, the elf assembles and glues the toys together, one after the other. This concurrent processing means that the glue from the first toy has time to dry (without needing more attention from the elf) while the remaining toys are glued together. The same goes for painting, one toy at a time, and finally wrapping.

Since one elf can only do one task at a time, a single elf is using the day as efficiently as possible by concurrently producing presents.

Parallelism

Hopefully, Santa’s workshop has more than just one elf. With more elves, more toys can be built simultaneously over the course of a day. This simultaneous work means that the presents are being produced in parallel. Parallel processing carried out by multiple elves means more work happens at the same time.

Elves working in parallel can also employ concurrency. One elf can still tackle only one task at a time, so it’s most efficient to have multiple elves concurrently producing presents.

Of course, if Santa’s workshop has, say, two-and-a-half million elves, each elf would only need to finish a maximum of one present per day. In this case, working sequentially doesn’t detract from the workshop’s efficiency. There would still be 7,668.26 elves left over to fetch coffee and lunch.

Santa Claus, and threading

After all the elves’ hard work is done, it’s up to Santa Claus to deliver the presents – all 907,208,752 of them.

Santa doesn’t need to make a visit to every kid; just to the one household tree. So how many trees does Santa need to visit? Again with broad generalization, we’ll say that the average number of children per household worldwide is 2.45, based on the year’s predicted fertility rates. That makes 370,289,286.4 houses to visit. Let’s round that up to 370,289,287.

How long does Santa have? The lore says one night, which means one earthly rotation, and thus 24 hours. NORAD confirms.

This means Santa must visit 370,289,287 households in 24 hours (86,400 seconds), at a rate of 4,285.75 households per second, never mind the time it takes to put presents under the tree and grab a cookie.

Clearly, Santa doesn’t exist in our dimension. This is especially likely given that, despite being chubby and plump, he fits down a chimney (with a lit fire, while remaining unhurt) carrying a sack of toys containing presents for all the household’s children. We haven’t even considered the fact that his sleigh carries enough toys for every believing boy and girl around the world, and flies.

Does Santa exist outside our rules of physics? How could one entity manage to travel around the world, delivering packages, in under 24 hours at a rate of 4,285.75 households per second, and still have time for milk and cookies and kissing mommy?

One thing is certain: Santa uses the Internet. No other technology has yet enabled packages to travel quite so far and quite so quickly. Even so, attempting to reach upwards of four thousand households per second is no small task, even with the best gigabit internet hookup the North Pole has to offer. How might Santa increase his efficiency?

There’s clearly only one logical conclusion to this mystery: Santa Claus is a multithreaded process.

A single thread

Let’s work outward. Think of a thread as one particular task, or the most granular sequence of instructions that Santa might execute. One thread might execute the task, put present under tree. A thread is a component of a process, in this case, Santa’s process of delivering presents.

If Santa Claus is single-threaded, he, as a process, would only be able to accomplish one task at a time. Since he’s old and a bit forgetful, he probably has a set of instructions for delivering presents, as well as a schedule to abide by. These two things guide Santa’s thread until his process is complete.

Single-threaded Santa Claus might work something like this:

1. Land sleigh at Timmy’s house
2. Get Timmy’s present from sleigh
3. Enter house via chimney
4. Locate Christmas tree
5. Place Timmy’s present under Christmas tree
6. Exit house via chimney
7. Take off in sleigh

Rinse and repeat… another 370,289,286 times.

Multithreading

Multithreaded Santa Claus, by contrast, is the Doctor Manhattan of the North Pole. There’s still only one Santa Claus in the world; however, he has the amazing ability to multiply his consciousness and accomplish multiple instruction sets of tasks simultaneously. These additional task workers, or worker threads, are created and controlled by the main process of Santa delivering presents.

Each worker thread acts independently to complete its instructions. Since they all belong to Santa’s consciousness, they share Santa’s memory and know everything that Santa knows, including what planet they’re running around on, and where to get the presents from.

With this shared knowledge, each thread is able to execute its set of instructions in parallel with the other threads. This multithreaded parallelism makes the one and only Santa Claus as efficient as possible.

If an average present delivery run takes an hour, Santa need only spawn 4,286 worker threads. With each making one delivery trip per hour, Santa will have completed all 370,289,287 trips by the end of the night.

Of course, in theory, Santa could even spawn 370,289,287 worker threads, each flying to one household to deliver presents for all the children in it! That would make Santa’s process extremely efficient, and also explain how he manages to consume all those milk-dunked cookies without getting full. ????

An efficient and merry multithreaded Christmas

Thanks to modern computing, we now finally understand how Santa Claus manages the seemingly-impossible task of delivering toys to good girls and boys the world-over. From my family to yours, I hope you have a wonderful Christmas. Don’t forget to hang up your stockings on the router shelf.

Of course, none of this explains how reindeer manage to fly.