[
https://issues.apache.org/jira/browse/JCS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148178#comment-15148178
]
Ben Manes commented on JCS-119:
-------------------------------
Since JDK6 update 22, the advise to prefer ReentrantLock over synchronized no
longer holds true. Since then further optimizations have let intrinsic locks
perform slightly better (except when biased locking causes headaches).
A concurrent LRU is non-trivial for a variety of reasons. You might prefer
decorating my
[ConcurrentLinkedHashMap|https://github.com/ben-manes/concurrentlinkedhashmap]
for JDK6 (or [Caffeine|https://github.com/ben-manes/caffeine] for JDK8). JCS is
strong on the framework aspects and weak on concurrent data structures, so the
pairing might be a good fit.
> replace synchronized blocks by java locks or concurrenhashmap
> -------------------------------------------------------------
>
> Key: JCS-119
> URL: https://issues.apache.org/jira/browse/JCS-119
> Project: Commons JCS
> Issue Type: Improvement
> Reporter: Romain Manni-Bucau
> Fix For: jcs-2.0-beta-2
>
>
> A cache is typically used in a concurrent environment. Since Java 6 using a
> ReentrantLock is faster than synchronized so can be interesting to replace
> synchronized blocks by a lock.
> Places i'm thinking about:
> * CompositeCache
> * AbstractDoubleLinkedListMemoryCache
> * LHMLRUMemoryCache
> * DoubleLinkedList
> * LRUMap
> * SingleLinkedList
> * SortedPreferentialArray
> Some places where replacing a HashMap by a ConcurrentHashMap can allow to get
> rid of synchronized without needing a lock:
> * CacheEventQueue
> * AbstractDiskCache
> * CacheWatchRepairable
> There are other places but this is the main I saw.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
