A cautionary tale on thread locals, pooling and reflection
Published on by Robert Munteanu on rombertw.wordpress.comMost non-trivial Java applications use thread pools to improve performance by avoiding thread creation and optionally by limiting the maximum numbers of threads in use. The end goal is for each task to execute in a dedicated thread, without it being aware that the thread is not a fresh one, but was used before. Starting with Java 5 the Java runtime libraries offer a wealth of options for creating thread pools in the java.util.concurrent package. So far, all is well – we have a simple, robust way of adding thread pooling to our application. That is, unless we are running code which is out of our control and is misbehaving. One kind of particularly subtle misbehaviour is using ThreadLocal storage and never cleaning that up. If you’re not familiar with thread-local storage in Java, this kind of access allows each thread to store its own value for a certain variable. The example...
Tags
comments powered by Disqus
Get Insights from the AGC!
Related Posts

How to Incorporate Front End Builds into OSGi Bundles
Jan 15, 2018
Dan Klco

Apache Sling IDE Tooling 1.2 Released
Jan 20, 2018
Robert Monteanu
New Sling Docker Image
Feb 8, 2018
Robert Munteanu