On Tue, 21 Jun 2022 09:35:34 GMT, Attila Szegedi <att...@openjdk.org> wrote:
>> This behaves slightly different from the old initialization; the concurrent >> hash map blocks when the mapping function is run, just in case if >> non-blocking instantiation is what we want. If that's not a problem, I would >> prefer szegedi's suggestion. > > @liach advance apologies for nitpicking: `ConcurrentHashMap` doesn't in > general block while the mapping function runs. It can block _some_ concurrent > updates, namely those that [hash to the same > bin](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/0f801fe6fd2fcc181121f9846f6869ca3a03e18a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java*L324__;Iw!!ACWV5N9M2RV99hQ!M8p-0NV01EacnHQD8Y5232_Rt40p54kS34M63XfK0EUN2_xI4QBo2zVeveUTw_ZurSoBFa079sXr7GdmArz-$ > ) and it won't block concurrent reads. I'm not saying the concern you raised > isn't valid, just wanted to clarify that the situation is not nearly as grave > as overall blocking; after all it ain't a `Collections.synchronizedMap` :-) Yeah, since `putIfAbsent` may block `get` calls, the blocking of `computeIfAbsent` is minuscule as long as the creation code is efficient enough. Just be careful that when writing the lambda for `computeIfAbsent`, preferably write static lambdas (that doesn't use `this`, instances, or local variables) so that one lambda can be reused over time than having to create a new one on each invocation. ------------- PR: https://git.openjdk.org/jdk/pull/9208
