java.util.UUID實習/回收

Question

Java中的UUID是否像字符串一樣被保留？ 如果不是，我是否應該嘗試回收UUID對象以最小化RAM使用？

我使用UUID作為數據庫主鍵和外鍵列的數據類型。 因此，這意味着許多行重復使用UUID作為共享外鍵值。

因此，從數據庫檢索行時，是否應該檢查每個UUID是否重復，如果重復，則使用原始對象引用嗎？ 還是已經代表我完成了此操作，類似於String的嵌入方式 ？

…  // common JDBC code
UUID id = null ;
while (rs.next()) {
    UUID idFresh = rs.getObject( 1 ); 
    // Recycle the UUID object where possible.
    id = ( ( null == id ) || idFresh.equals( id ) ) ? idFresh : id ;  // If null or identical, use the existing object reference.
    String name = rs.getString( 2 );
}
…

Answer 1

快速瀏覽一下Java運行時源代碼，就會發現UUID沒有被固定。

實習生它們可能不是一個好主意，因為如果要遍歷大型數據庫，UUID實習可能會導致JVM耗盡內存，這僅僅是因為它從未預知過它所見過的任何UUID。

同樣，內部UUID並沒有太大好處，因為

• 他們不占用太多空間
  （基本上只是將UUID的128位值存儲為一對long ）

• UUID比較和哈希碼計算很便宜。
  （ String實習的最大好處之一是String的哈希碼僅計算一次，這有點令人擔憂，因為它的計算可能會稍微昂貴一些。）

Answer 2

UUID（以及字符串）不會自動進行重復數據刪除。 通常，這也不是一個好主意，因為新創建的UUID應該是唯一的，因此共享將不起作用。

當您提到字符串實習時，確實JVM將在特定情況下共享字符串，例如：

String x = "ab";
String y = "a" + "b";
assert x == y; // references are identical (x and y are shared)

這些是字符串，但是可以在編譯時解析。 如果在運行時創建字符串或UUID，它將始終創建一個新對象。

在您的問題中，您描述了另一種情況。 在這里，您正在從數據庫中讀取UUID。 根據數據，可能有共享UUID的好機會，也可能沒有（例如，如果將UUID用作主密鑰）。

id | name  | country
1  | A     | <UUID-1>
2  | B     | <UUID-1>
3  | C     | <UUID-2>
4  | D     | <UUID-1>
5  | E     | <UUID-1>

（請注意，從數據庫或網絡讀取UUID時，您不能假定將對UUID進行重復數據刪除。通常，您會收到相同值的副本。）

因此，如果您的數據如上所示，則可以共享UUID。 但這會減少內存使用嗎？

UUID是具有兩個long變量的對象。 在64位JVM中，這將占用32個字節。 如果您共享UUID，則只需支付32個字節一次，之后僅支付8個字節作為參考。 如果使用壓縮指針 ，則引用將適合4個字節。

這個收益足夠大嗎？ 這取決於您的特定應用程序。 通常，我不會共享UUID。 但是，我已經開發了一個應用程序，在其中共享UUID確實是一個改進。 減少內存使用量至關重要，從完整對象減少到引用是一項改進。

話雖如此，很少需要這種優化。 根據經驗，只有在大量共享UUID且有必要不惜一切代價減少內存的情況下，我才會這樣做。 否則，對它們進行重復數據刪除的CPU開銷以及代碼中的額外復雜性通常是不值得的，或者更糟的是，甚至可能減慢您的應用程序的速度。

如果您決定對它們進行重復數據刪除，將如何進行？ 沒有像String#intern這樣的內置函數，但是您可以手動創建要進行重復數據刪除的映射。 根據您是要在當前函數調用中全局刪除重復數據還是僅在本地重復數據刪除，可以使用ConcurrentHashMap或僅使用（非同步的） HashMap 。

---

作為附帶說明，與您的問題沒有直接關系，我提到了String#intern因為它是String API的一部分。 但是，強烈建議您不要使用它，因為這是一個巨大的性能瓶頸 。 自己進行重復數據刪除將明顯更快。