Hey folks,
I’ve been looking at some performance bottlenecks in a system recently, and
found that we have some that stem from synchronizing on a SimpleDateFormat
(which, as we know, isn’t thread safe.) This got me thinking about switching to
a ThreadLocal of them, but I realized that I don’t need one for each thread,
just enough otherwise identical instances to avoid contention.
That further made me think of how it’d be nice to have a class that can
instantiate a requisite number of identical instances of a non-threadsafe
class, and provide locked access to a consumer I pass to it, internally
managing the contention in a similar way to how e.g. LongAccumulator does (or
rather, the Striped64 class underlying it), including all the appreciable
details that went into that logic such as advancing the Threads'
threadLocalRandomProbe to slowly converge on a perfect hash function etc.
So it’s essentially an object pool somewhere between a ThreadLocal and
Striped64. I don’t have a good name for it; “WeakThreadLocal” or “ThreadRental”
come to mind as it’d allow threads to essentially “rent" these objects :-) Its
API would roughly be:
public final class WeakThreadLocal<T> {
public WeakThreadLocal(Supplier<T> newInstance);
public void use(Consumer<T> user);
}
and then I could do:
var dateFormats = new WeakThreadLocal(
// invoked to create instances as contention dictates
()=>new SimpleDateFormat(…)
);
…
dateFormats.use(dateFormat => … while this runs, only this thread has access to
this dateFormat)
Is there anything obviously wrong/hard with this idea? (Aside from the
admittedly material problem where the pooled class should itself take care
against false sharing.) How useful would a class like this be in general?
Thanks for any insights,
Attila.
