Thread Weak Local / Thread Rental

[Attila Szegedi]

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.