<div dir="ltr">Hi all,<div><br></div><div>This is my first time posting on this list, been follower for quite some time now and really enjoying all the knowledge sharing :) .</div><div><br></div><div>I was looking on optimizing a solution today at work, and I came across the following.</div>
<div>We have a scenario where we keep a simple cache (HashMap) and this is accessed by multiple</div><div>readers on an application server, millions of times per day and highly contented. This cache is immutable and only gets updated by a single writer by replacing the reference that the variable points to every 5 mins. This is currently done as a volatile field. I was looking for a way to lose completely the memory barriers and rely on that field being eventually visible across all other threads (no problem by reading stale data for a few seconds).</div>
<div><br></div><div>Would that be possible with the current JMM ? I tried to test that scenario with some code, and it seems to work most of the times, but some threads read stale data for longer that I would expect (lots of seconds). Is there any platform dependency on such implementation ? Its going to run on x86 environments. Is there any assumption we can make as of how long that 'eventually' part can be ? (could it be more than 5 mins, when the next write occurs?). My understanding is that, that write even if re-ordered will have to happen. I came across an article about using the AtomicReference doing a lazySet (store-store) for the write, and then the Unsafe to do a getObject (direct) instead of the default get which is based on the volatile access. Would that be a better solution?</div>
<div><br></div><div>Any ideas, alternatives?</div><div><br></div><div>PS. Sorry for the question-bombing :/</div><div><br></div><div>Regards,</div><div>Thomas</div><div>
</div></div>