You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branch:
observability
3.0.x
3.1.x
3.2.x
4.0.x
4.1.x
4.2.x
4.3.x
5.0.x
5.1.x
5.2.x
5.3.x
6.0.x
CoWebFilter
beanbuilder
conversation
docs-build
gh-pages
main
observability
v3.0.0.M1
v3.0.0.M2
v3.0.0.M3
v3.0.0.M4
v3.0.0.RC1
v3.0.0.RC2
v3.0.0.RC3
v3.0.0.RELEASE
v3.0.1.RELEASE
v3.0.1.RELEASE-A
v3.0.1.RELEASE.A
v3.0.2.RELEASE
v3.0.3.RELEASE
v3.0.4.RELEASE
v3.0.5.RELEASE
v3.0.6.RELEASE
v3.0.7.RELEASE
v3.1.0.M1
v3.1.0.M2
v3.1.0.RC1
v3.1.0.RC2
v3.1.0.RELEASE
v3.1.1.RELEASE
v3.1.2.RELEASE
v3.1.3.RELEASE
v3.1.4.RELEASE
v3.2.0.M1
v3.2.0.M2
v3.2.0.RC1
v3.2.0.RC2
v3.2.0.RC2-A
v3.2.0.RELEASE
v3.2.1.RELEASE
v3.2.10.RELEASE
v3.2.11.RELEASE
v3.2.12.RELEASE
v3.2.13.RELEASE
v3.2.14.RELEASE
v3.2.15.RELEASE
v3.2.16.RELEASE
v3.2.17.RELEASE
v3.2.18.RELEASE
v3.2.2.RELEASE
v3.2.3.RELEASE
v3.2.4.RELEASE
v3.2.5.RELEASE
v3.2.6.RELEASE
v3.2.7.RELEASE
v3.2.8.RELEASE
v3.2.9.RELEASE
v4.0.0.M1
v4.0.0.M2
v4.0.0.M3
v4.0.0.RC1
v4.0.0.RC2
v4.0.0.RELEASE
v4.0.1.RELEASE
v4.0.2.RELEASE
v4.0.3.RELEASE
v4.0.4.RELEASE
v4.0.5.RELEASE
v4.0.6.RELEASE
v4.0.7.RELEASE
v4.0.8.RELEASE
v4.0.9.RELEASE
v4.1.0.RC1
v4.1.0.RC2
v4.1.0.RELEASE
v4.1.1.RELEASE
v4.1.2.RELEASE
v4.1.3.RELEASE
v4.1.4.RELEASE
v4.1.5.RELEASE
v4.1.6.RELEASE
v4.1.7.RELEASE
v4.1.8.RELEASE
v4.1.9.RELEASE
v4.2.0.RC1
v4.2.0.RC2
v4.2.0.RC3
v4.2.0.RELEASE
v4.2.1.RELEASE
v4.2.2.RELEASE
v4.2.3.RELEASE
v4.2.4.RELEASE
v4.2.5.RELEASE
v4.2.6.RELEASE
v4.2.7.RELEASE
v4.2.8.RELEASE
v4.2.9.RELEASE
v4.3.0.RC1
v4.3.0.RC2
v4.3.0.RELEASE
v4.3.1.RELEASE
v4.3.10.RELEASE
v4.3.11.RELEASE
v4.3.12.RELEASE
v4.3.13.RELEASE
v4.3.14.RELEASE
v4.3.15.RELEASE
v4.3.16.RELEASE
v4.3.17.RELEASE
v4.3.18.RELEASE
v4.3.19.RELEASE
v4.3.2.RELEASE
v4.3.20.RELEASE
v4.3.21.RELEASE
v4.3.22.RELEASE
v4.3.23.RELEASE
v4.3.24.RELEASE
v4.3.25.RELEASE
v4.3.26.RELEASE
v4.3.27.RELEASE
v4.3.28.RELEASE
v4.3.29.RELEASE
v4.3.3.RELEASE
v4.3.30.RELEASE
v4.3.4.RELEASE
v4.3.5.RELEASE
v4.3.6.RELEASE
v4.3.7.RELEASE
v4.3.8.RELEASE
v4.3.9.RELEASE
v5.0.0.M1
v5.0.0.M2
v5.0.0.M3
v5.0.0.M4
v5.0.0.M5
v5.0.0.RC1
v5.0.0.RC2
v5.0.0.RC3
v5.0.0.RC4
v5.0.0.RELEASE
v5.0.1.RELEASE
v5.0.10.RELEASE
v5.0.11.RELEASE
v5.0.12.RELEASE
v5.0.13.RELEASE
v5.0.14.RELEASE
v5.0.15.RELEASE
v5.0.16.RELEASE
v5.0.17.RELEASE
v5.0.18.RELEASE
v5.0.19.RELEASE
v5.0.2.RELEASE
v5.0.20.RELEASE
v5.0.3.RELEASE
v5.0.4.RELEASE
v5.0.5.RELEASE
v5.0.6.RELEASE
v5.0.7.RELEASE
v5.0.8.RELEASE
v5.0.9.RELEASE
v5.1.0.RC1
v5.1.0.RC2
v5.1.0.RC3
v5.1.0.RELEASE
v5.1.1.RELEASE
v5.1.10.RELEASE
v5.1.11.RELEASE
v5.1.12.RELEASE
v5.1.13.RELEASE
v5.1.14.RELEASE
v5.1.15.RELEASE
v5.1.16.RELEASE
v5.1.17.RELEASE
v5.1.18.RELEASE
v5.1.19.RELEASE
v5.1.2.RELEASE
v5.1.20.RELEASE
v5.1.3.RELEASE
v5.1.4.RELEASE
v5.1.5.RELEASE
v5.1.6.RELEASE
v5.1.7.RELEASE
v5.1.8.RELEASE
v5.1.9.RELEASE
v5.2.0.M1
v5.2.0.M2
v5.2.0.M3
v5.2.0.RC1
v5.2.0.RC2
v5.2.0.RELEASE
v5.2.1.RELEASE
v5.2.10.RELEASE
v5.2.11.RELEASE
v5.2.12.RELEASE
v5.2.13.RELEASE
v5.2.14.RELEASE
v5.2.15.RELEASE
v5.2.16.RELEASE
v5.2.17.RELEASE
v5.2.18.RELEASE
v5.2.19.RELEASE
v5.2.2.RELEASE
v5.2.20.RELEASE
v5.2.21.RELEASE
v5.2.22.RELEASE
v5.2.23.RELEASE
v5.2.24.RELEASE
v5.2.25.RELEASE
v5.2.3.RELEASE
v5.2.4.RELEASE
v5.2.5.RELEASE
v5.2.6.RELEASE
v5.2.7.RELEASE
v5.2.8.RELEASE
v5.2.9.RELEASE
v5.3.0
v5.3.0-M1
v5.3.0-M2
v5.3.0-RC1
v5.3.0-RC2
v5.3.1
v5.3.10
v5.3.11
v5.3.12
v5.3.13
v5.3.14
v5.3.15
v5.3.16
v5.3.17
v5.3.18
v5.3.19
v5.3.2
v5.3.20
v5.3.21
v5.3.22
v5.3.23
v5.3.24
v5.3.25
v5.3.26
v5.3.27
v5.3.28
v5.3.29
v5.3.3
v5.3.30
v5.3.4
v5.3.5
v5.3.6
v5.3.7
v5.3.8
v5.3.9
v6.0.0
v6.0.0-M1
v6.0.0-M2
v6.0.0-M3
v6.0.0-M4
v6.0.0-M5
v6.0.0-M6
v6.0.0-RC1
v6.0.0-RC2
v6.0.0-RC3
v6.0.0-RC4
v6.0.1
v6.0.10
v6.0.11
v6.0.12
v6.0.13
v6.0.2
v6.0.3
v6.0.4
v6.0.5
v6.0.6
v6.0.7
v6.0.8
v6.0.9
v6.1.0-M1
v6.1.0-M2
v6.1.0-M3
v6.1.0-M4
v6.1.0-M5
v6.1.0-RC1
v6.1.0-RC2
${ noResults }
src-spring-framework/spring-jdbc
Brian Clozel
c470262c8e
Prior to this commit, the `ConcurrentLruCache` implementation would not perform well under certain conditions. As long as the cache capacity was not reached, the cache would avoid maintaining an eviction queue (reordering entries depending with least/most recently read). When the cache capacity was reached, the LRU queue was updated for each read/write operation. This decreased performance significantly under contention when the capacity was reached. This commit completely rewrites the internals of `ConcurrentLruCache`. `ConcurrentLruCache` is now a specialized version of the `ConcurrentLinkedHashMap` [1]. This change focuses on buferring read and write operations, only processing them at certain times to avoid contention. When a cached entry is read, a read operation is queued and buffered operations are drained if the buffer reached a fixed limit. When a new cache entry is added or removed, a write operation is queued and triggers a drain attempt. When the capacity is outgrown, the cache polls items from the eviction queue, which maintains elements with the least recently used ones first. Entries are removed until the capacity is under control. The behavior described here and the buffer sizes are optimized with the number of available processors in mind. Work is localized as much as possible on a per-thread basis to avoid contention on the eviction queue. The new implementation has been tested with the JMH benchmark provided here, comparing the former `COncurrentLruCache`, the new implementation as well as the `ConcurrentLinkedHashMap` [1]. When testing with a cache reaching capacity, under contention, with a 10% cache miss, we're seeing a 40x improvement compared to the previous implementation and performance on par with the reference. See [2] for how to replicate the benchmark. [1] https://github.com/ben-manes/concurrentlinkedhashmap [2] https://github.com/spring-projects/spring-framework/wiki/Micro-Benchmarks Closes gh-26320 |
2 years ago | |
---|---|---|
.. | ||
src | Rewrite ConcurrentLruCache implementation | 2 years ago |
spring-jdbc.gradle | Jakarta EE 9 migration | 3 years ago |