Le fil SecureRandom est-il sûr?

Question

Est-ce que SecureRandom thread est sans danger? En d’autres termes, après l’initialisation, l’accès au prochain nombre aléatoire peut-il être considéré comme sûr pour le thread? L'examen du code source semble montrer que c'est le cas, et ce rapport de bogue semble indiquer que son manque de documentation en tant que thread-safe est un problème lié à javadoc. Quelqu'un a-t-il confirmé qu'il s'agit bien d'un thread-safe?

Answer 1

Oui, il est. Il utilise la synchronisation à protéger l'intégrité de son état.

Il pourrait être possible pour un fournisseur de remplacer les méthodes pertinentes, sans synchronisation, mais il y a beaucoup de code là-bas en s'appuyant sur le , de facto, le contrat de thread-safe SecureRandom, donc cela ne peut être signalé comme un bug.

Si le nombre de threads à l'aide d'un seul SecureRandom, il y a peut être conflit que ce qui affecte les performances. D'autre part, l'initialisation de l' SecureRandom instance peut être relativement lente. Si c'est mieux que de partager un mondial RNG, ou pour en créer un nouveau pour chaque thread dépendra de votre application.

---

Mise à jour: Java 7 rend une garantie explicite de fil de sécurité pour Random des cas. Toutefois, il souligne également que la demande pour un seul Random exemple dans une application multi-thread peut nuire à la performance, et introduit l' ThreadLocalRandom classe comme une solution.

Answer 2

L'implémentation actuelle de l' SecureRandom est thread-safe, en particulier les deux une mutation des méthodes d' nextBytes(bytes[]) et setSeed(byte[]) sont synchronisés.

Eh bien, autant que je l'ai été en mesure de dire, tous les mutation méthodes sont par la suite acheminés par le biais de ces deux méthodes, et SecureRandom des remplacements de quelques méthodes en Random pour s'assurer que. Ce qui fonctionne, mais pourrait être fragile si la mise en œuvre est modifié dans le futur.

La meilleure solution est de synchroniser manuellement sur l' SecureRandom première instance. Cela signifie que chaque pile d'appel fera l'acquisition de deux verrous sur le même objet, mais qui est généralement très bon marché moderne de la Jvm. Qui est, il n'y a pas beaucoup de mal explicitement la synchronisation de vous-même. Par exemple:

    SecureRandom rnd = ...;

    byte[] b = new byte[NRANDOM_BYTES];
    synchronized (rnd) {
        rnd.nextBytes(b);
    }

Answer 3

Toute personne qui pense que SecureRandom (ou l’une ou l’autre de ses méthodes) est-elle thread-safe peut-elle indiquer ici où ils ont obtenu leurs informations? Code source? Ce que j'ai trouvé, c'est un rapport de bogue se plaignant du manque de documentation appropriée concernant ce problème (ou pire, de synchronisation): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6498354

Answer 4

Oui. C'est totalement thread-safe. En fait, je me plaindrais que le verrou est trop agressif. L'ensemble engineNextBytes() est synchronisé.

Pour être franc avec vous, je ne saurais pas si ce n'est pas sûr. Le problème des threads introduit probablement plus de hasard :)