[concurrency-interest] thread safety of java.lang.reflect.Field

David Holmes davidcholmes at aapt.net.au
Thu May 31 18:55:46 EDT 2018

The java.lang.reflect classes are not specified to be thread-safe. They probably should be specified that way but they aren't.

The implementation is quite complex in places and it is hard to determine whether they are thread-safe in practice. I can see some initialization race conditions with caching of field state (like getGenericInfo()) that theoretically could expose default rather than actual values.


> -----Original Message-----
> From: Concurrency-interest <concurrency-interest-bounces at cs.oswego.edu> On Behalf Of Novi via Concurrency-interest
> Sent: Thursday, May 31, 2018 7:31 PM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] thread safety of java.lang.reflect.Field
> Hello,
> I wonder if instances of java.lang.reflect.Field can be shared between multiple threads as long as the accessibility flag is either not
> modified or modified exactly once prior to a safe publication of the field instances.
> In other words, is it legal to cache instances of j.l.r.Field between multiple threads?
> Best Regards,
> Novi
> PS: The Bean Validation reference implementation Hibernate Validator seems to cache instances of j.l.r.Field across threads.
> However, I couldn't find any clue in the Java API documentation whether such a usage is supported or not.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list