Impact of high CPU usage on a background thread execution in Java

Context

There are many ways of creating a “background thread” in Java. I want to spin off exactly one thread that keeps running in the background. I’m using ScheduledExecutorService for this.

I want that thread to run at a fixed interval of 2 seconds (between consecutive executions). This thread makes a network call to a service with a total timeout of 1 second.

As I understand, specifying a priority to a thread is an OS dependent behavior and is merely a suggestion to the OS to prioritize that thread over other threads in the system.

Question

What is the guarantee that my thread will continue executing at a regular interval (at least once every 3 seconds) despite the CPU usage shooting up (say >= 70%) ?
~~Is there a way of guaranteeing this? Is this a platform dependent question?~~ Removing this to make this Q more focused on the essentials.

Update: Clarification

Some details about the background thread’s characteristics:

The majority of the thread’s time will be spent in performing a blocking REST API call using JAX-RS with JerseyClient’s implementation.
The remaining time is spent in doing cheap processing work that involves processing a JSON response of < 1 KB and updating an in-memory HashMap.
This thread will be running in a Web app processing requests in an AWS ECS cluster (auto-scaling enabled) – and we wouldn’t want the CPU to go beyond 70%. It will only shoot up beyond 70% due to an unexpected spike which is extremely rare.
If the thread gets delayed beyond 3 seconds once in ~1000 times (works 99.9% times), it should be okay. So I don’t need it to be real-time (100%).

Also, when I mentioned 70% CPU, I meant 70% of the overall compute capacity available to the application (including cores etc).

Conventional computing

You asked:

What is the guarantee that my thread will continue executing at a regular interval (at least once every 3 seconds) despite the CPU usage shooting up (say >= 70%) ?

None, no guarantee at all.

In a conventional JVM, all code executes on a native “platform” thread created, managed, and scheduled by the host OS. When that thread gets scheduled for execution is completely up to the host OS, not the JVM. Every OS implementation (macOS, BSD, Linux, AIX, Windows, etc.) has its own policies and algorithms for managing threads. Those policies and algorithms may change from version to version. And those policies and algorithms are likely dynamic, adapting to changing situations at runtime such as demands on memory and CPU cores.

By the way, if your task in Java involves significant blocking, without long-running code that is native (FFM, JNI) or using synchronized, then generally best to use Java virtual threads for better performance.

Now, three seconds is a long time on modern computers. During that time about 10 billion operations per core could be performed, for about 100 billion operations, on a 8-10 core computer — not even counting GPU cores. So likely your thread will be scheduled for execution during a good chunk of every three second chunk of time. But there is no guarantee. It is entirely possible that your thread may not be scheduled for execution for three seconds or more, especially if the computer is severely overburdened such as in virtual-memory thrashing. Obviously it is vital that deployment is continually managed by a capable sysadmin to ensure that computers are not overburdened.

As far as your number 70%, remember that today’s computers have multiple cores. So a six-core CPU has 600% capacity. A number like 70% CPU utilization means that not even one core’s worth of computing capacity is being used, and that means most (or all) cores are spending most of their time idle.

Is there a way of guaranteeing this?

No, no way of guaranteeing predictable regular execution.

Is this a platform dependent question?

Every platform will behave somewhat differently in regard to scheduling threads for execution on cores. But overall the effects are similar. Every OS wants to service as many threads as often as possible. Every OS wants to utilize all available resources as effectively and efficiently as possible.

If the thread gets delayed beyond 3 seconds once in ~1000 times (works 99.9% times), it should be okay. So I don’t need it to be real-time (100%).

If you:

Ensure the deployment computer is never overburdened
Have multiple cores (perhaps with hyper-threading disabled)
Use virtual threads (throttled if your tasks are expensive)

… then I would expect your performance targets to be met.

You could record the elapsed time of your executions (Instant, Duration, JMX) to monitor actual performance.

This Answer assumes we are speaking of a dedicated physical computer. If you are doing cloud deployment, all bets are off. Cloud systems are easily overburdened given that the real hardware is being shared amongst multiple virtual tenants. Any rogue tenant can swamp the machine at any time. I imagine progress has been made in recent years to limit such impacts, but I would plan for cloud deployments to be occasionally swamped. If performance is critical, use dedicated physical hardware.

Real-time computing

As commented, if you need absolute guarantees about performance and execution scheduling, then you must use specialized hardware with a specialized operating system running a specialized Java implementation. We are talking aerospace, military, and nuclear reactor kinds of specialties. Real-time computing is the technical term. That is an entirely different kind of computing than buy-a-MacBook-at-the-BestBuy computing.

Filed under: Kiến thức lập trình - @ 00:12

Thẻ: javabackground-processcpu-usagejava-threads

Thiết kế website giá rẻ

Danh mục