[
https://issues.apache.org/jira/browse/LANG-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502098
]
Michael Sclafani commented on LANG-334:
---------------------------------------
Well, the bug description refers to two enum classes, but your test only uses
one enum class, so I'm completely unsurprised you didn't replicate the problem.
The bug is caused by one thread calling getEnum(A.class, 0) while another
thread is initializing B.class, and those two threads are excuting in such a
way that the first thread is reading the cEnumClasses map while the second
thread is modifying the same map by registering the mapping for B.class. If you
use only one enum class, the bug won't be seen. If you use two enum classes,
but statically reference them so that both classes are initialized before
getEnum() is called, no bug. If you use two classes, or ten classes, or 10000
classes, but fail to overlap the threads reading the map and writing the map in
just the right (or wrong) way, no bug.
Unit testing isn't a great approach for testing synchronization problems since
it's impossible for the test to control the execution order, especially when
the bug requires actual concurrency. This bug cropped up when we started using
new multi-core hardware. I could write a unit test for you, but I wouldn't
expect it to fail unless you had identical hardware and software.
> Enum is not thread-safe
> -----------------------
>
> Key: LANG-334
> URL: https://issues.apache.org/jira/browse/LANG-334
> Project: Commons Lang
> Issue Type: Bug
> Reporter: Michael Sclafani
> Fix For: 2.3.1
>
> Attachments: EnumPlay.java
>
>
> Enum uses no synchronization. Even if you assume that instances are only
> declared statically, the cEnumClasses map is global and can be written to
> when a thread triggers static initialization of B.class while some other
> thread is doing getEnumList(A.class). Unsynchronized access of a map
> undergoing mutation is not thread-safe.
> This isn't theoretical. We're seeing ValuedEnum.getEnum(X.class, 0) return
> null after returning the correct value over 100,000 times, and then return
> the correct value again on the next invocation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
