Why java.util.UUID.randomUUID Can Block Threads and How to Fix It

UUID (Universally Unique Identifier) is a 128‑bit identifier generated in Java via java.util.UUID.randomUUID(). It relies on the operating system’s entropy sources; when entropy is low, the SecureRandom call blocks, causing the calling thread to be BLOCKED.

How randomUUID works

The method uses the OS entropy pool (e.g., mouse movement, hardware noise). If the kernel cannot gather enough entropy, SecureRandom slows down, and any thread invoking java.util.UUID.randomUUID() may be put into a BLOCKED state.

Real‑world impact

An example thread dump from a production application shows 50 out of 102 threads stuck in BLOCKED while calling java.util.UUID.randomUUID(). The stack trace reveals the block occurs inside java.security.SecureRandom.nextBytes.

"[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'" waiting for lock java.security.SecureRandom@20a56b2b BLOCKED
java.security.SecureRandom.nextBytes(SecureRandom.java:433)
java.util.UUID.randomUUID(UUID.java:159)
... (additional stack frames omitted for brevity)

Solutions

Upgrade the JDK

The blocking behavior is a known bug fixed in JDK 8 u112 and later (including JDK 9 b105). Updating the runtime eliminates the issue.

Install a user‑space entropy daemon (haveged)

On Linux, installing the haveged package supplies additional entropy via the HAVEGE algorithm. Example installation commands:

sudo apt-get install rng-tools
sudo update-rc.d haveged defaults

sudo yum install rng-tools
sudo chkconfig haveged on

Use /dev/urandom instead of /dev/random

Configure the JVM to read from /dev/urandom by adding the system property: -Djava.security.egd=file:/dev/./urandom Note that /dev/urandom provides non‑blocking pseudo‑random numbers with slightly lower entropy, which may affect security‑sensitive applications.