[英]Specific usage of Hashtable over ConcurrentHashMap
ConcurrentHashMap
was introduced in 1.5 as a part java java.util.concurrent
package. ConcurrentHashMap
作为java java.util.concurrent
包的一部分在1.5中引入。 Before that the only way to have a threadsafe
map was to use HashTable
or Collections.synchronizedMap(Map)
. 在此之前,拥有
threadsafe
映射的唯一方法是使用HashTable
或Collections.synchronizedMap(Map)
。
For all the practical purpose (multithread environment), ConcurrentHashMap
is sufficient to address the needs except one case wherein a thread needs a uniform view of the map. 出于所有实际目的(多线程环境),
ConcurrentHashMap
足以满足需求,除了一个线程需要统一的地图视图的情况。
My question is, apart from having a Uniform View of the map, are there any other scenarios wherein ConcurrentHashMap
is not an option ? 我的问题是,除了有一个统一的地图视图,还有其他任何情况,其中
ConcurrentHashMap
不是一个选项?
The usage of Hashtable
has been discouraged since Java 1.2 and the utility of synchronizedMap
is quite limited and almost always ends up being insufficient due to the too-fine granularity of locking. 不鼓励使用
Hashtable
因为Java 1.2和synchronizedMap
的实用程序非常有限,并且由于过于精细的锁定粒度,几乎总是不够用。 However, when you do have a scenario where individual updates are the grain size you need, ConcurrentHashMap
is a no-brainer better choice over synchronizedMap
. 但是,当您确实有个别更新是您需要的粒度时,
ConcurrentHashMap
比synchronizedMap
更好的选择。 It has better concurrency, thread-safe iterators (no, synchronizedMap
doesn't have those—this is due to its design as a wrapper around a non-thread-safe map), better overall performance, and very little extra memory weight to pay for it all. 它具有更好的并发性,线程安全的迭代器(不,
synchronizedMap
没有那些 - 这是由于它的设计作为非线程安全映射的包装器),更好的整体性能,以及非常少的额外内存权重支付为了这一切。
This is a stretch but I will give it as a use case. 这是一个延伸,但我将它作为一个用例。
If you needed a thread-safe Map implementation which you can do some extra compound operation on which isn't available via ConcurrentMap
. 如果您需要一个线程安全的Map实现,您可以通过
ConcurrentMap
进行一些额外的复合操作。 Let's say you want to ensure two other objects don't exist before adding a third. 假设您要在添加第三个对象之前确保不存在其他两个对象。
Hashtable t = new Hashtable();
synchronized(t){
if(!t.contains(object1) && !t.contains(object2)){
t.put(object3,object3);
}
}
Again this is a stretch, but you would not be able to achieve this with a CHM while ensuring atomicity and thread-safety. 同样,这是一个延伸,但在确保原子性和线程安全性的同时,您无法通过CHM实现这一目标。 Because all operations of a
Hashtable
and its synchronizedMap
counter part synchronize on the instance of the Map this ensures thread-safety. 因为
Hashtable
所有操作及其synchronizedMap
计数器部分在Map的实例上同步,所以这确保了线程安全性。
At the end of the day I would seldom, if ever, use a synchronizedMap
/ Hashtable
and I suggest you should do the same. 在一天结束时,我很少(如果有的话)使用
synchronizedMap
/ Hashtable
,我建议你也应该这样做。
As far as I understand, ConcurrentMap
is a replacement of HashTable
and Collections.synchronizedMap()
for thread-safe purposes. 据我所知,
ConcurrentMap
是HashTable
和Collections.synchronizedMap()
的替代品,用于线程安全目的。 A usage of that all classes is discouraged. 不鼓励使用所有类。 Thus, the answer to your question is "no, there are no other scenarios".
因此,您的问题的答案是“不,没有其他情况”。
See also: What's the difference between ConcurrentHashMap and Collections.synchronizedMap(Map)? 另请参见: ConcurrentHashMap和Collections.synchronizedMap(Map)之间有什么区别?
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.