|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-02-17
synchronize写程序很麻烦， 不容易操作 并发包解决了这些问题。
|
| 返回顶楼 | |
|
发表时间：2009-02-17
最后修改：2009-02-17
你可以这么理解
synchronized是jvm内部实现的; 而Concurrent是用Java语言写出来的(就是用java语言把synchronized在jvm内部实现写出来);依靠cpu的cas实现,感觉像乐观锁; segments那个只是concurrentHashMap里面的一种优化 上面是仅仅是个人理解, |
| 返回顶楼 | |
|
发表时间：2009-02-17
julyboxer 写道 ConcurrentHashMap的性能优异的原因是把Map分离成多份，这样更新的时候只要锁定其中一份，而不需要全部锁住。就像数据库中只需要锁定其中一行，而不需要锁住全表的道理类似。。
正解! 
|
| 返回顶楼 | |
|
发表时间：2009-02-17
最后修改：2009-02-17
引用 The allowed concurrency among update operations is guided by the optional concurrencyLevel constructor argument (default 16), which is used as a hint for internal sizing. The table is internally partitioned to try to permit the indicated number of concurrent updates without contention. Because placement in hash tables is essentially random, the actual concurrency will vary. Ideally, you should choose a value to accommodate as many threads as will ever concurrently modify the table. Using a significantly higher value than you need can waste space and time, and a significantly lower value can lead to thread contention. But overestimates and underestimates within an order of magnitude do not usually have much noticeable impact. A value of one is appropriate when it is known that only one thread will modify and all others will only read. Also, resizing this or any other kind of hash table is a relatively slow operation, so, when possible, it is a good idea to provide estimates of expected table sizes in
这个是ConcurrentHashMap类注释的一部分,注意这个词"concurrencyLevel"它的默认值是16. 锁分离是并发编程中比较常用技术,但是将锁分离用在hashmap上是有一定难度的,hashmap是数组+链表(桶)实现的,而且随着元素的增多,还会产生rehash操作,这样每把分离锁的作用域也会改变,对并发没有一定见地的人是写不出来的 |
| 返回顶楼 | |
|
发表时间：2009-02-20
佩服楼主对问题群追猛大,一直"杀"到的底的魄力!
|
| 返回顶楼 | |
|
发表时间：2009-02-23
并发真是很头疼的
问题`有时候出的很莫名其妙`````` 不想面对`但又不得不去面对`` |
| 返回顶楼 | |
|
发表时间：2009-02-23
pior 写道 并发真是很头疼的问题`有时候出的很莫名其妙``````不想面对`但又不得不去面对`` 遵寻一些模式，使用一些封装好的库（特别是JDK中自带的一些类库），减少代码量，应该会好很多 |
| 返回顶楼 | |
