I've read some article which saying that CHM is still locked, it just divid the hashmap into few small hashmap internally so that the chance of lock-wait is lesser, is that wrong?
On Fri, Dec 3, 2010 at 10:19 PM, Gregg Wonderly <[email protected]> wrote: > On 12/2/2010 3:48 PM, Patricia Shanahan wrote: >> >> Gregg Wonderly wrote: >> ... >>> >>> A second issue is that if you are designing a "container" class that >>> others >>> might use in multiplicity such that it could end up in a container, and >>> perhaps as a key data structure, it can be better to create an internal >>> locking object to perform synchronization on so that if the user of your >>> class >>> starts using your class as a locking object, the internal locking does >>> not >>> impact unrelated code paths. >> >> ... >> >> For container objects, I would give the opposite advice, and recommend >> making >> the container itself the lock object. > > There are cases for both I believe. ConcurrentHashMap, for example has no > locks performed on the instance. All locking is internal using mechanisms > other than synchronized. > > The primary issue with using an internal lock, for me, is that I've found > that I end up with less opportunity for circular wait if I am in complete > control of when a lock is asserted. > > For things where atomic views need to maintained through multiple operations > on the same instance, then a single global view lock will be important. As > the user of the container instance, you are more able to understand that > need in your application, so locking is your responsibility. > > Many people have complained about CHM not being "the lock" itself, but it > really comes down to the fact that since it does not use synchronized > actions internally, it can not make the object be "the lock". > > With this in mind, I've started trying to internalize more locking so that > for things that I do need to "adjust internal performance" on, I don't have > to go everywhere else and change locking use to be in line with the change > from synchronized to Lock. > > Locking with instances via synchronized was convenient, but I'd suggest that > not doing that provides a more plastic model that you can more readily > adjust. > > I also find that I will put more application operations into the APIs to > help me control and optimize those usage patterns. This seems to help me > create more relevant/useful APIs and fewer "containers". I.e. more simple > algorithms end up in the class implementation instead of strewn about the > application. > > Gregg Wonderly >
