struts2 - Java Thread Safety Issue in Struts ScopeInterceptor class? -
i'm trying understand if there thread-safety issue inside of struts2 scopeinterceptor class (/org/apache/struts2/interceptor/scopeinterceptor.java), here's code in question:
private static map locks = new identityhashmap(); static final void lock(object o, actioninvocation invocation) throws exception { synchronized (o) { int count = 3; object previous = null; while ((previous = locks.get(o)) != null) { if (previous == invocation) { return; } if (count-- <= 0) { locks.remove(o); o.notify(); throw new strutsexception("deadlock in session lock"); } o.wait(10000); } ; locks.put(o, invocation); } } static final void unlock(object o) { synchronized (o) { locks.remove(o); o.notify(); } }
i have websphere application showing 45 stalled threads, high cpu usage. 33 threads stalled @ "locks.remove(o)" inside of "unlock" method. other 12 threads stalled inside of "locks.get(o)" inside of "lock" method.
it seems me usage of identityhashmap thread-unsafe. wrapping identityhashmap collections.synchronizedmap() solve problem?:
private static map locks = collections.synchronizedmap(new identityhashmap()); static final void lock(object o, actioninvocation invocation) throws exception { synchronized (o) { int count = 3; object previous = null; while ((previous = locks.get(o)) != null) { if (previous == invocation) { return; } if (count-- <= 0) { locks.remove(o); o.notify(); throw new strutsexception("deadlock in session lock"); } o.wait(10000); } ; locks.put(o, invocation); } } static final void unlock(object o) { synchronized (o) { locks.remove(o); o.notify(); } }
it seems me author tried "fix" identityhashmap's synchronization problem using synchronized code blocks, doesn't protect against multiple threads if object "o" thread-specific object. and, since code blocks within lock , unlock separate, identityhashmap (and does!) called simultaneously more 1 thread (as per our java core evidence).
is collections.synchronizedmap() wrapper correct fix, or missing something?
i believe right, , there appears thread safety issue. developer attempting thread safe synchronizing on object "o", looks object session object rather scoped more widely. believe change needs to synchronize on locks object.
Comments
Post a Comment