Random numbers and UUIDs

Q: What are the most common mistakes with Random numbers and UUIDs?

Using Random or Math.random for tokens and passwords. Creating a new Random() in a tight loop (same seed for several calls). Sharing one Random heavily between many threads.

Random produces repeatable pseudo-random numbers from a seed, SecureRandom produces unpredictable ones for security, and UUID.randomUUID() creates a practically unique 128-bit identifier.

🔎 Unravel this example

At a glance

Mental model

Random is a shuffled deck whose order is fully decided by the shuffling recipe (the seed): same recipe, same order.

What happens, in order

1new Random(42) gives the same sequence every run, ideal for repeatable tests and simulationsnew Random() seeds from the clock. rnd.nextInt(10) is 0 to 9.
2In concurrent code use ThreadLocalRandom.current().nextInt(1, 7), which avoids contention on a shared generator
3Anything security related (tokens, passwords, session ids, salts, keys) needs SecureRandom; Random is predictable after a few outputs
4UUID.randomUUID() is a random version-4 id such as 3f1c...; collisions are practically impossible, and they can be created without asking a database

Remember

Random UUIDs are poor database primary keys for large indexed tables (inserts scatter across the index)
Shuffle with Collections.shuffle(list, rnd); picking a random element with list.get(rnd.nextInt(list.size())) can bias if you reduce a larger random number by % yourself
Random is a 48-bit linear congruential generator, which is why its output can be reconstructed

Watch out

Using Random or Math.random for tokens and passwordsCreating a new Random() in a tight loop (same seed for several calls)Sharing one Random heavily between many threads

Example (highlighted lines explain it)

import java.security.SecureRandom;import java.util.*;public class Tokens {  private static final SecureRandom RNG = new SecureRandom();  static String newToken() { byte[] b = new byte[16]; RNG.nextBytes(b); return Base64.getUrlEncoder().withoutPadding().encodeToString(b); }  static String newId() { return UUID.randomUUID().toString(); }  static int roll(Random r) { return r.nextInt(6) + 1; }}

line 1 uses SecureRandom, the core of Random numbers and UUIDs
line 4 uses SecureRandom, the core of Random numbers and UUIDs
line 5 uses nextBytes, the core of Random numbers and UUIDs
line 6 uses UUID, the core of Random numbers and UUIDs
line 7 uses Random, the core of Random numbers and UUIDs

Read the full explanation (about 1 min)

Random produces repeatable pseudo-random numbers from a seed, SecureRandom produces unpredictable ones for security, and UUID.randomUUID() creates a practically unique 128-bit identifier.

A mental model

Random is a shuffled deck whose order is fully decided by the shuffling recipe (the seed): same recipe, same order. SecureRandom is a deck shuffled by watching real-world noise, so nobody can predict the next card.

How it works

new Random(42) gives the same sequence every run, ideal for repeatable tests and simulations. new Random() seeds from the clock. rnd.nextInt(10) is 0 to 9.

In concurrent code use ThreadLocalRandom.current().nextInt(1, 7), which avoids contention on a shared generator.

Anything security related (tokens, passwords, session ids, salts, keys) needs SecureRandom; Random is predictable after a few outputs.

UUID.randomUUID() is a random version-4 id such as 3f1c...; collisions are practically impossible, and they can be created without asking a database.

Going deeper

Random UUIDs are poor database primary keys for large indexed tables (inserts scatter across the index). Time-ordered ids (UUIDv7, ULID, snowflake) keep inserts local.

Shuffle with Collections.shuffle(list, rnd); picking a random element with list.get(rnd.nextInt(list.size())) can bias if you reduce a larger random number by % yourself.

SecureRandom can block on some systems at startup when entropy is low; reuse one instance instead of creating one per call.

Under the hood

Random is a 48-bit linear congruential generator, which is why its output can be reconstructed. SecureRandom delegates to the operating system (for example /dev/urandom) or a cryptographic DRBG.

Common mistakes

Using Random or Math.random for tokens and passwords.
Creating a new Random() in a tight loop (same seed for several calls).
Sharing one Random heavily between many threads.

How Unravel recognises it

When you paste code, Unravel looks for these signs of random numbers and uuids. Spotting them yourself is a good habit when you read unfamiliar code:

Types: Random SecureRandom ThreadLocalRandom UUID
Method calls: Math.random() nextInt() nextDouble() nextBoolean() randomUUID() nextBytes() ints()

Part of a learning path

Text, numbers and arrays · previous: Math and number utilities · next: Arrays and the Arrays utilities

Related concepts

Hashing, Base64 and encryptionI/O and data Math and number utilitiesJava language

Frequently asked questions

What is Random numbers and UUIDs?

Random produces repeatable pseudo-random numbers from a seed, SecureRandom produces unpredictable ones for security, and UUID.randomUUID() creates a practically unique 128-bit identifier.

What are the most common mistakes with Random numbers and UUIDs?

Using Random or Math.random for tokens and passwords. Creating a new Random() in a tight loop (same seed for several calls). Sharing one Random heavily between many threads.

How can I see Random numbers and UUIDs in real code?

Paste your own Java into Unravel and it will point out where random numbers and uuids appears, explain how it works at the detail level you choose, and draw the flow of the code around it.