Chủ đề SecureRandom có ​​an toàn không?

Là SecureRandomchủ đề an toàn không? Tức là, sau khi khởi tạo nó, có thể dựa vào việc truy cập vào số ngẫu nhiên tiếp theo để an toàn cho luồng không? Việc kiểm tra mã nguồn dường như cho thấy điều đó, và báo cáo lỗi này dường như chỉ ra rằng việc thiếu tài liệu làm an toàn luồng là một vấn đề javadoc. Có ai xác nhận rằng nó trong thực tế là chủ đề an toàn?

Vâng, đúng vậy. Nó mở rộng Random, luôn có triển khai an toàn luồng trên thực tế , và từ Java 7, đảm bảo rõ ràng an toàn luồng.

Nếu nhiều luồng đang sử dụng một luồng duy nhất SecureRandom, có thể có sự tranh cãi làm ảnh hưởng đến hiệu suất. Mặt khác, việc khởi tạo một SecureRandomthể hiện có thể tương đối chậm. Việc chia sẻ RNG toàn cầu là tốt nhất hay tạo một RNG mới cho mỗi luồng sẽ tùy thuộc vào ứng dụng của bạn. Các ThreadLocalRandomlớp có thể được sử dụng như một mô hình để cung cấp một giải pháp mà hỗ trợ SecureRandom.

Việc triển khai hiện tại SecureRandomlà an toàn theo luồng, đặc biệt là hai phương pháp đột biến nextBytes(bytes[])và setSeed(byte[])được đồng bộ hóa.

Chà, theo như tôi có thể nói, tất cả các phương thức đột biến cuối cùng đều được định tuyến thông qua hai phương thức đó và SecureRandomghi đè một vài phương thức Randomđể đảm bảo điều đó. Phương pháp này hoạt động nhưng có thể bị hỏng nếu việc triển khai bị thay đổi trong tương lai.

Giải pháp tốt nhất là đồng bộ hóa thủ công trên SecureRandomphiên bản đầu tiên. Điều này có nghĩa là mỗi ngăn xếp cuộc gọi sẽ thu được hai khóa trên cùng một đối tượng, nhưng điều đó thường rất rẻ trên các JVM hiện đại. Có nghĩa là, không có nhiều tác hại trong việc đồng bộ hóa rõ ràng bản thân. Ví dụ:

    SecureRandom rnd = ...;

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