java.time.ZoneOffset contains two internal caches to cache ZoneOffset instances for each multiple of 15 minute offsets:

- SECONDS_CACHE: with integer keys (seconds)
- ID_CACHE: with string keys (formatted offsets)

The SECONDS_CACHE is used in the value constructor method ZoneOffset.ofTotalSeconds(int), which again is used by a few other methods.

In a profiling session, I've noticed that the access to the ConcurrentHashMap tends to be noticeable. The attached OffsetZoneCacheBenchmark.java compares using the native ConcurrentHashMap cache with an eagerly constructed ZoneOffset[] cache, similar to the java.lang.Integer.IntegerCache and related boxed Number caches.

A ZoneOffset[] cache would contain 145 ZoneOffset values only (multiples of 15 minute offsets going from [-18 hours, +18 hours]), which makes eager allocating such a cache through a static initialiser reasonable.

The benchmark results indicate a roughly 50% performance improvement from replacing the ConcurrentHashMap cache by a static ZoneOffset[] cache, which hints at this improvement being worthwhile for further investigation:

Benchmark Mode Cnt Score Error Units
OffsetZoneCacheBenchmark.testAlternative thrpt 21 163052589.815 ± 12040875.428 ops/s
OffsetZoneCacheBenchmark.testNative thrpt 21 98849171.257 ± 6670874.543 ops/s

The ID_CACHE would not be affected by this improvement, apart from the fact that it also would have to be eagerly allocated.