How to shoot yourself in the foot by a random number generator

Prevent immediately that here you will not find an explanation how the random number generators, and why they obtained using numbers are not that random. There is only a theory, so, alas, after reading this article, you do not learn to hack slot machines.

In this post, we'll discuss a quite common problem encountered when using a random number generator in the standard library Java.

First, let's look at how the class java.util.Random works by using multiple threads. Its objects thread safe, but nevertheless, the simultaneous use of the same object of this class in different streams synchronized. As we found this often leads to significant slowing down of the application because of the fact that several threads attempt to simultaneously access the same resource.

At first it may not seem the most pressing problem. How often do you need to do something unpredictable in your enterprise application? On the contrary, it is necessary to follow the hard-coded business rules. It should be recognized that sometimes these so-called "rules" even more random than generators really a randomly numbers, but that's another story ...

As always, the devil is in the details, and in this case it is a subclass of java.util.Random -java.util.SecureRandom. As its name implies, it is used if the output of the generator should be cryptographically resistant. By unknown reasons nobody objects of this class are used in situations where cryptographic resistance, it would seem, it does not matter.

We noticed this unpleasant feature when developing tools to automatically detect problems of interaction between threads and locks. Judging by the results of our work, one of the most common problems occur when calling innocuous-looking method java.io.File.createTempFile(). It uses the class SecureRandom, to determine the name of the file to be created. Let's look at the code:

1 2 3 4 5 6 7 8 9 10

private static final SecureRandom random = new SecureRandom(); static File generateFile(String prefix, String suffix, File dir) {     long n = random.nextLong();     if (n == Long.MIN_VALUE) {         n = 0;      // крайний случай     } else {         n = Math.abs(n);     }     return new File(dir, prefix + Long.toString(n) + suffix); }

When calling nextLong () object class SecureRandom resorted to his method nextBytes (),which is declared as synchronized:

1 2 3

synchronized public void nextBytes(byte[] bytes) {     secureRandomSpi.engineNextBytes(bytes); }

We can say that if you create a new instance of SecureRandom in each stream, then no problem. Unfortunately, not everything is so simple. SecureRandom uses an abstract class java.security.SecureRandomSpi, all copies will turn to him so that the difficulties can not be avoided(here under discussion this bug, there can also be found in the performance tests it).

All this, under certain circumstances (especially if your application uses SSL-connection, which rely on when making SecureRandom hendsheyka) necessarily result in long-term decline in productivity.

Correct the situation if you can modify the application code, it is easy - just use java.util.ThreadLocalRandom under multithreading. However, it may also happen that the problem lies in the standard API - then serious refactoring can not be avoided.

What is the moral of the story? Working with streams should be careful. Especially if your instruments for development is not taken into account. In any case, we hope that this article will prevent libraries where random number generation will be a stumbling block.