保证String.intern()线程安全吗? [英] String.intern() thread safety guaranteed?
问题描述
是否有任何书面证明保证String.intern()是线程安全的? Javadoc暗示了它，但没有直接解决它:
Is there any documented guarantee that String.intern() is thread safe? The javadoc alludes to it but does not address it directly:
返回字符串对象的规范表示.一池 最初为空的字符串由类String私有维护.
Returns a canonical representation for the string object. A pool of strings, initially empty, is maintained privately by the class String.
调用intern方法时，如果池中已经包含一个 等于由equals(Object)确定的此String对象的字符串 方法，然后返回池中的字符串.不然这样 将String对象添加到池中，并对此String进行引用 对象被返回.
When the intern method is invoked, if the pool already contains a string equal to this String object as determined by the equals(Object) method, then the string from the pool is returned. Otherwise, this String object is added to the pool and a reference to this String object is returned.
因此，对于任意两个字符串s和t，s.intern()== t.intern() 当且仅当s.equals(t)为true时为true.
It follows that for any two strings s and t, s.intern() == t.intern() is true if and only if s.equals(t) is true.
所有文字字符串和字符串值常量表达式均为 实习生.字符串文字在The的第3.10.5节中定义. Java™语言规范.
All literal strings and string-valued constant expressions are interned. String literals are defined in section 3.10.5 of the The Java™ Language Specification.
值得注意的是，javadoc表示可以保证返回池中的字符串，但不能保证池本身是线程安全的(因此，在编写时，它似乎为在事件中替换池条目打开了方便之门.竞争线程，尽管我认为这种解释不太可能.
Notably, the javadoc says that a String from the pool is guaranteed to be returned, but not that the pool itself is thread safe (so as written it appears to leave the door open for a pool entry to be replaced in the event of competing threads, although I think this interpretation is unlikely).
String的JDK源表明intern()是一种本地方法，并未对其线程安全性有任何了解:
And the JDK source of String shows intern() to be a native method which does not shed any light on its thread safety:
public native String intern();
我的关注点具体涉及以下内容是否完全线程安全，从而保证针对面对每个唯一字符串值，仅创建一个MyObject (不仅存储在缓存中).并发请求:
My concern is specifically related to whether the following would be fully thread safe, guaranteeing only one MyObject is created (not merely stored in the cache) for each unique string value in the face of concurrent requests:
public void myMethod(String myString)
{
// Get object from cache, the cache itself is thread safe
MyObject object = myCache.get(myString);
if (object == null)
{
synchronized(myString.intern())
{
// Retry cache to avoid race condition
object = myCache.get(myString);
if (object == null)
{
object = new MyObject(myString);
// ... do some startup / config of the object ...
myCache.put(object);
}
}
}
// do something useful with the object
}
我希望避免在方法或缓存本身上进行同步，因为创建对象可能会花费一些时间(需要网络访问).有一些变通办法，例如维护本地线程安全的高速缓存/字符串池，但是除非有必要，否则不值得这样做. String.intern()的内存含义(无法从缓存中删除内部字符串)与该特定用例(正在使用的字符串数量较少)无关.
I wish to avoid synchronizing on either the method or the cache itself since the creation of the object can take some time (entails network access). There are workarounds such as maintaining a local thread safe cache / pool of strings but it is not worth doing unless necessary. The memory implications of String.intern() (inability to remove interned strings from the cache) are not relevant for this particular use case (small number of strings being used).
我相信String.intern()是线程安全的，并且上面的代码还不错，但是缺乏可靠来源的直接确认使我有些担心.
I believe that String.intern() is thread safe and that the code above is fine, but the lack of direct confirmation from a reputable source leaves me slightly concerned.
此问题曾在这里多次问过，但未提供参考文献的具体答案:
This question has been asked here multiple times before, but no concrete answer with references has been provided:
- Is String.Intern() thread safe
- How do intern'd strings behave between different threads and classloaders?
推荐答案
这听起来像是您可能想要番石榴怪异的副作用如果您使用的其他任何代码也有相同的想法.
That actually sounds like you might want a Guava Striped<Lock>, which maps objects to locks in a hashed way. Synchronizing on interned strings seems like a potentially dangerous hack that could have weird side effects if any other code you're using had the same idea.
这篇关于保证String.intern()线程安全吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
