[Java Performance] JVM Threading Tuning

Adjust line stacks space

When memory is very scarce, you can adjust the memory used by the thread. Each thread has a stack that records the call stack information for that thread. The default space for a stack in a thread is determined by the version of the OS and JVM:

OS	32-bit	64-bit
Linux	KB	1 MB
Mac OS	N/A	1 MB
Solaris Sparc	KB	1 MB
Solaris X86	KB	1 MB
Windows	KB	1 MB

When the stack space is set over an hour, stackoverflowerror may be thrown because of a longer call stack.

In a 64-bit JVM, it is generally not necessary to modify this value unless the memory is indeed very tight. In a 32-bit JVM, this value can be set from 320KB to 128KB, freeing up more space for heap memory.

Instructions for rerouting stacks space: -Xss=N For example:-Xss=256k

Prejudice lock (biased Locking)

When a lock is contested by multiple threads, the JVM and OS can choose which thread to assign the lock to. You can use a fair policy to assign locks to other threads, or you can use an unfair (biased) policy, such as assigning a lock to the last thread that owns the lock.

Assigning a lock again to the last thread that owns the lock is justified by the fact that, due to time continuity, the processor may also cache data related to the task performed by the thread, so that when the thread executes again, the time to prepare the context can be saved. Of course, using the bias lock itself requires a record of some relevant data, so at some point it will have an impact on performance.

Typically, for example, in many cases, if you apply a bias lock to a thread pool, performance will become worse. If an app does not need to use a bias lock as a policy for lock allocation, you can disable it by: by -XX:-UseBiasedLocking default, biased locking is enabled, and disabling it can improve performance.

Spin of the Lock (lock Spinning)

For threads that do not have a lock, the JVM is handled in two ways:

• Let the thread enter a busy loop (Busy loop), and once it executes some instructions, it will check again if the required lock is available.
• Let the thread enter a queue and notify it when the required lock is available. At this point the CPU can be used by other threads.

If a lock that is in competition only needs to be held for a short period of time, then using the first busy loop (also known as thread Spinning) will be much faster than the second way to get the thread into the queue. Conversely, when a lock in a competition is held by a thread for a longer period of time, the second way is better, which makes the CPU more efficient to use.

The JVM makes a reasonable choice of which processing to use. First, the thread spins for a period of time, and if the required lock is not available, the thread is placed in the queue to wait for it to yield the CPU resources to other threads.

Thread Priority

In the Java API, each thread can be set to a priority, and the OS will refer to this value. But note that the OS is simply "reference" and does not necessarily follow it. The OS calculates a "current" priority for each running thread. This calculation takes precedence over the set, but it is only one of many factors, the most important of which is how long the thread has been running. Consider this factor to allow each thread to get the chance to run. So, regardless of how low the priority of the thread is set, they always get the chance to run.

In addition, the weight of the thread priority set on the different OS is different. On Unix-based systems, the execution time of a thread is a factor in the current priority of the dominant thread, which means that the thread priority set is rarely "referenced". On Windows systems, the weight of the thread priority you set is slightly higher.

So, regardless of the OS, the performance of the application cannot depend on the priority of the thread setting. If some tasks have precedence over other tasks, this needs to be done by the application's logic rather than by setting the thread's priority.

One way to assign tasks to different thread pools, and then set the size of those thread pools.

[Java Performance] JVM Threading Tuning