這將不是說明隨機數生成器畢竟不是那么隨機的文章之一。 因此，您中的那些人希望獲得有關如何破解老虎機，繼續(xù)前進的指南，在這里什么也看不到。

相反，它是有關一個不太常見的鎖爭用問題的帖子，該問題隱藏在Java API的隨機數生成器中。

要打開該主題，讓我們開始研究如何在java.util.Random類中處理并發(fā)。 java.util.Random的實例是線程安全的。 但是，在線程之間并發(fā)使用同一java.util.Random實例是同步的，并且我們已經發(fā)現(xiàn)趨向于觸發(fā)影響應用程序性能的爭用問題。

在您的日常企業(yè)應用程序中，這聽起來似乎不是一個重要的問題–畢竟，您實際上有多少次實際執(zhí)行了故意無法預測的事情？ 相反，您只是在按照可預見的方式遵循業(yè)務規(guī)則。 我必須承認，盡管在某些情況下，這些業(yè)務規(guī)則比真正的隨機種子生成算法所涉及的熵甚至更大，但這完全是另一回事。

但是，魔鬼隱藏在細節(jié)中，在這種情況下，碰巧是java.util.Random的子類，即java.util.SecureRandom 。 此類，如名稱所述，應在隨機數生成器的結果必須是加密安全的情況下使用。 由于人類未知的原因，在通常不希望隨機性的密碼安全方面具有重要意義的情況下，該實現(xiàn)已被選擇為許多常見API的主干。

我們通過密切關注鎖爭用檢測解決方案的采用來親身體驗這個問題。 根據結果??，通過看上去無害的java.io.File.createTempFile（）調用觸發(fā)了Java應用程序中最常見的鎖定問題之一。 在后臺，這種臨時文件的創(chuàng)建依賴于SecureRandom類來計算文件的名稱。

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; // corner case} else {n = Math.abs(n);}return new File(dir, prefix + Long.toString(n) + suffix); }

然后，在調用nextLong時，SecureRandom最終調用其方法nextBytes（） ，該方法定義為synced ：

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

有人會說，如果我在每個線程中創(chuàng)建新的SecureRandom，我將不會遇到任何問題。 不幸的是，這并不是那么簡單。 SecureRandom使用java.security.SecureRandomSpi的實現(xiàn)，無論如何最終都會爭奪它（您可能會在Jenkins問題跟蹤器中看到以下帶有一些基準的bug討論）

這與某些應用程序使用模式結合在一起（尤其是如果您有許多SSL連接依靠SecureRandom來實現(xiàn)其加密握手魔術），則有形成長期持久爭用問題的趨勢。

如果您可以控制源代碼，則解決此問題的方法很簡單–只需重建解決方案即可依靠java.util.ThreadLocalRandom進行多線程設計。 如果您堅持使用標準API，則解決方案可能會更復雜，并且需要大量重構。

故事的道德啟示？ 并發(fā)很難。 尤其是在您的系統(tǒng)構建塊沒有考慮到這一點時。 無論如何，我確實希望這篇文章至少從兩個新庫的誕生中拯救世界，在新庫中，隨機數生成器將成為競爭點。

翻譯自: https://www.javacodegeeks.com/2015/03/shooting-yourself-in-the-foot-with-random-number-generators.html

總結

以上是生活随笔為你收集整理的用随机数发生器射击自己的脚的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。