ben-manes commented on PR #17879: URL: https://github.com/apache/kafka/pull/17879#issuecomment-2499032785
The eviction selection is not part of the external contract, which tries to convey that the cache is allowed a lot of leniency on its choices. The technical details are shared in engineering docs because its fun and interesting. The policy's goal is merely to maximize the hit rate which is a very fuzzy topic as every workload has different characteristics, so we try to have a balanced way to be near optimal in all cases, whereas alternative policies tend to have spectacular failure cases. Any test that assumes a deterministic eviction order is already broken because the cache includes some randomization to [defeat](https://github.com/ben-manes/caffeine/blob/a31defdc6751136fe47cf81fdc18a70923488da5/caffeine/src/main/java/com/github/benmanes/caffeine/cache/BoundedLocalCache.java#L165-L173) denial of service attacks. For the cache's tests we work around this by [unsafely forcing](https://github.com/ben-manes/caffeine/blob/a31defdc6751136fe47cf81fdc18a70923488da5/caffeine/src/test/java/com/github/benmanes/caffeine/cache/Reset.java#L40-L44) the `ThreadLocalRandom` seeds, meaning going deeply into implementation details. A small tuning change like that one or refactoring can have a subtle impact that does not change the net hit rate. For example if one modifies the hashing function then different counter collisions might impact frequency estimates. This could cause an inconsequential difference in the eviction choice for the overall hit rate (e.g. when both the candidate and victim entries are reasonable to evict). Please do not depend on those types of implementation details. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
