使用java摘要的哈希生成會在時間上變慢

Question

在使用wildfly 8.2和Java 1.7的生產環境中，我有一個真正好奇的情況。

情況是，當服務器啟動超過2周時，登錄開始降低性能。 我一直在尋找可能表明問題所在的線索。 然后在做了一些測試之后，我得出結論，問題是當以純文本插入的密碼被加密以與已經插入的密碼進行比較時。

當執行加密密碼的功能時，大約需要2分鍾，但是當服務器重新啟動時，相同的執行時間不到30秒。

加密使用java.security.MessageDigest來生成哈希。 特別是使用SHA-256和50000次迭代。 知道為什么這個過程會隨着時間變慢嗎？ 我正在使用/ dev / urandom來生成隨機因此不應該是問題。

這是功能代碼：

protected byte[] hash(byte[] bytes, byte[] salt, int hashIterations) throws UnknownAlgorithmException {
    MessageDigest digest = getDigest(getAlgorithmName());
    if (salt != null) {
        digest.reset();
        digest.update(salt);
    }
    byte[] hashed = digest.digest(bytes);
    int iterations = hashIterations - 1; //already hashed once above
    //iterate remaining number:
    for (int i = 0; i < iterations; i++) {
        digest.reset();
        hashed = digest.digest(hashed);
    }
    return hashed;
}

Answer 1

經過一天的研究，我終於找到了問題的答案。 我想在這里分享它，以防它對其他人有用。

問題是由於代碼緩存而導致的。 我專注於堆內存，我沒有看到任何問題，但是當我檢查非堆內存時，我發現就像登錄過程開始減慢一樣，代碼緩存上有一半以上的下降使用的記憶。

調查這個內存，我發現當這個空間有大量丟棄時，可能會發生JIT編譯器停止工作。 總而言之，這就是發生的事情，並且關閉JIT編譯器導致我的加密循環的每次迭代都必須在每次執行時被解釋，這在邏輯上使得進程慢得多。

在這里，我留下一些我認為對本主題有幫助的鏈接。

[1] - https://www.quora.com/In-Java-what-exactly-will-the-JVM-interpreter-and-the-JIT-compiler-do-with-the-bytecode

[2] - https://www.atlassian.com/blog/archives/codecache-is-full-compiler-has-been-disabled

感謝那些花時間回答它的人

Answer 2

擺脫語句： int iterations = hashIterations - 1; 並只使用hashIterations 。

在最好的情況下，它將迭代從50000（在所述情況下）減少到49999，並且在最壞的情況下導致整數下溢並且將迭代增加到int的最大值。

當hashIterations為零時，至少要防止減1 。

還可以通過記錄iterations的值來考慮用於調試的檢測。

Answer 3

為什么有人會關閉這個？ 也許是因為沒有什么可能導致問題。

雖然digest.digest通常是耗時的部分，但它是一個純粹的計算，沒有什么可以減慢它的速度。 剩下的就是getAlgorithmName()和getDigest(String) 。 前者可能是一個微不足道的getter，但后者可能使用MessageDigest.getInstance來定位摘要。 只是猜測：有一個查找所有安全提供程序及其提供的所有內容，有人可能會以某種方式延長此列表。

您甚至可以在生產中對此庫方法進行基准測試 ：只需將該方法復制到新的源文件中，然后添加一些日志記錄和一些定期調用它的代碼（如果您願意，還可以手動調用）。 當發生減速時，你會有一些東西需要比較，你會在日志中找到一些詳細的時間。

當所有可以想象的原因都用盡時，嘗試不可想象的原因，例如不同的iterations （你認為這是一個常數），等等。