Fix SharedLock ThreadLocal threadWriters memory leak may cause CPU usage to reach 100%
This PR SharedLock.decrementWriters() to call threadWriters.remove() when the per-thread writer depth reaches zero, preventing unused ThreadLocal entries from lingering. This helps avoid the ThreadLocalMap.expungeStaleEntry() CPU spikes reported in #3489
Thanks !
Make sure that:
- [x] You have read the contribution guidelines.
- [x] You have created a feature request first to discuss your contribution intent. Please reference the feature request ticket number in the pull request.
- [x] You applied code formatting rules using the
mvn formatter:formattarget. Don’t submit any formatting related changes. - [x] You submit test cases (unit or integration tests) that back your changes.
This might actually work. @tishun what do you think ?
Thanks for your feedback 🙂 I agree your comment
Then, what do you think about reducing the remove() frequency based on probability or an idle count threshold ??
Hello again @bandalgomsu
Then, what do you think about reducing the remove() frequency based on probability or an idle count threshold ??
I think this will just slow down the memory leak a bit, but won't remove it. We need event driven solution of the problem - when the connection is closed - the lock should be removed. The problem is every thread holds a reference in his own ThreadLocal and there is no good way of expunging them manually. We need to rely on GC. But seems in some GC algorithms this process is delayed, which leads to accumulation of entries and than CPU intensive cleanup. I don't know what the solution might be at this point, but I don't think the general direction of this fix is right, thats why i will close this PR for now. Thank you for the effort and if you have new fresh ideas i am all ears :)