Q

是java.util.UUID線程安全嗎？

2011-08-27 376 views 23 likes

23

我問這個問題，因爲以下意見是java.util.UUID線程安全嗎？

獲得在線程轉儲該堆棧跟蹤高度多線程環境

"http-80-200" daemon prio=10 tid=0x00002aaab4981000 nid=0x7520 waiting \ 
for monitor entry [0x000000004fec7000] 
    java.lang.Thread.State: BLOCKED (on object monitor) 
    at java.security.SecureRandom.nextBytes(SecureRandom.java:433) 
    - waiting to lock <0x00000000c00da220> (a java.security.SecureRandom) 
    at java.util.UUID.randomUUID(UUID.java:162)

發現這個鏈接

http://bugs.sun.com/view_bug.do?bug_id=6611830

如果UUID不是線程安全的，請建議任何其他庫（如果存在）。

2011-08-27 Abhishek Gayakwad

+2

事實上，一個線程在'BLOCKED'狀態確實，本身並不意味着有問題。如果線程正在等待獲取同步方法或代碼塊的鎖定，則這是正常的。只有當線程永遠處於這種狀態纔可能意味着存在僵局。 – Jesper

+0

+ 1的鏈接（Josh Bloch的錯誤報告......） - 順便提一下，在錯誤報告中鏈接（http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev /）錯誤現在應該修復 –

A

回答

10

UUID是不可變的，所以它可能是線程安全的，但顯然在某些訪問器中有一些evil caching going on，這使得它不安全（該錯誤現在已修復）。

但你的線程轉儲只是說，一個線程正在等待在SecureRandom.nextBytes鎖，用於由UUID.randomUUID工廠，這絕對是線程安全的。據我所知，當多個線程同時調用它時，應該會發生這種情況。

2011-08-27 05:28:09

+0

在某些情況下，使用SecureRandom會使這種方法非常緩慢。如果你真的想要最好的比特，那麼使用這個比特源是很好的，但是如果你需要很多UUID（對於一個模擬來說），這可能會非常緩慢。 –

+0

由於這個錯誤在幾年前已經修復，這個答案應該說現在是線程安全的嗎？ – eis

-1

這是線程安全 ---這就是爲什麼我花了幾個星期來找出併發程序中這個邪惡類導致的瓶頸。

2012-02-24 18:00:43

+0

你可以圍繞這個瓶頸想出任何解決方法嗎？ – Ashish

+7

那麼你是說它是或不是線程安全的。諷刺在這裏並沒有真正的幫助。 – jtbradle

+1

請您清楚地回答您是否真的發現它是線程安全的。從你的回答來看，你的答案的讀者是沒有任何保證的。 –

0

UUID是線程安全的但有一種叫JUG 庫，它在性能上更加高效。

來源：http://www.dcalabresi.com/blog/java/generate-java-uuid-performance/

2017-05-21 13:21:04

相關問題