The BUFFER_COUNT computed in ConcurrentLruCache.ReadOperations seems suspicious, since it's basically always just 4; it seems like the intention was to size things based on number of CPUs, but using Math.min here with 4 means that we always just end up with the value 4 (unless it's a uniprocessor machine). If it was intentional then the logic in detectNumberOfBuffers can be simplified, and there's no reason to try to find the next largest power of two. It feels like maybe the intent was to clamp the value to be a min of 4, but to allow a higher max size?
I have yet to benchmark it yet, but it should be easy enough to test out changing the logic to allow for actual buffer count values > 4.
See: https://github.com/spring-projects/spring-framework/blob/main/spring-core/src/main/java/org/springframework/util/ConcurrentLruCache.java#L453
The
BUFFER_COUNTcomputed inConcurrentLruCache.ReadOperationsseems suspicious, since it's basically always just 4; it seems like the intention was to size things based on number of CPUs, but usingMath.minhere with 4 means that we always just end up with the value 4 (unless it's a uniprocessor machine). If it was intentional then the logic indetectNumberOfBufferscan be simplified, and there's no reason to try to find the next largest power of two. It feels like maybe the intent was to clamp the value to be a min of 4, but to allow a higher max size?I have yet to benchmark it yet, but it should be easy enough to test out changing the logic to allow for actual buffer count values > 4.
See: https://github.com/spring-projects/spring-framework/blob/main/spring-core/src/main/java/org/springframework/util/ConcurrentLruCache.java#L453