[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098110#comment-13098110
]
Julien Aymé commented on OGNL-20:
---------------------------------
Simone,
The complexity of lock/unlock operation is O(1) I think. But there is a cost
nonetheless.
The
[ConcurrentHashMap|http://download.oracle.com/javase/6/docs/api/java/util/concurrent/ConcurrentHashMap.html]
class javadoc explains the mechanism of its behavior, including:
{quote}
Retrieval operations (including get) generally do not block, so may overlap
with update operations (including put and remove).
...
The table is internally partitioned to try to permit the indicated number of
concurrent updates without contention.
{quote}
Also, the proposed code is rather:
{code}
Map _methodParameterTypesCache = new ConcurrentHashMap();
...
Class[] result;
if ( ( result = (Class[]) _methodParameterTypesCache.get( m )) == null )
{
_methodParameterTypesCache.putIfAbsent( m, result = m.getParameterTypes()
);
}
return result;
{code}
in which the {{m.getParameterTypes()}} is invoked only once per thread and only
as many times as there is concurrent threads trying to get the same value not
already computed (for the same key).
The whole point is that in a really ultra heavy environment (hundreds of
concurrent threads) the cache still behaves efficiently (a value computed in
one thread will be shared to others) without becoming a huge bottleneck (which
will happen when using either lock or synchronized block)
HTH,
De rien !!
Julien
P.S.: In french, we usually say "merci d'avance" for "thanks in advance" ;-)
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> ---------------------------------------------------------------------
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
> Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
