Repository navigation
Fix memory leaks in CacheHandler due to iteration failures - #1037
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9cdaa5d8f0
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
Please retain the existing ConcurrentHashMap<String, Object[]> declarations for the eight caches already using that type, and keep the original ConcurrentHashMap parameter on shouldSuppressRepeat. Changing these public declarations to Map breaks previously compiled callers with NoSuchFieldError/NoSuchMethodError, even though the underlying objects remain concurrent maps. Those type changes aren’t needed for the fix. The four synchronized-map conversions and the removeIf cleanup look good. With the existing declarations preserved, this should be good to merge. |
|
Thanks, should be good to go now. |
I was investigating a potential memory leak on our 300+ concurrent player Survival server, and found CacheHandler's lookupCache consuming over 9 GB of RAM.

The cleanup thread was iterating over Collections.synchronizedMap wrappers without taking the map's lock. The Collections#synchronizedMap javadoc says that "it is imperative to manually synchronize on the returned map when iterating over any of its collection views, otherwise behavior is non-deterministic". Under heavy load another thread would modify the map mid-iteration and the loop would throw. The catch block then breaked out of it, so the pass ended early and the expired entries stayed in memory. This repeated on every pass, so the cache only ever grew.
I've changed the caches that were using a synchronized map to ConcurrentHashMaps, like the other caches in the class. I also made cleanup use removeIf, which is safe while other threads write, and an entry with malformed data is now removed instead of ending the pass.
I also took the liberty of doing some type cleanup and removing the legacy concurrencyLevel parameters from the maps (since they don't really do anything on Java 8+).