[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.

["Jochen Theodorou (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804198#comment-17804198 ] 

Jochen Theodorou commented on GROOVY-11271:
-------------------------------------------

to add ore details: https://github.com/apache/groovy/blob/5a3cf7c86feacc6f257cc72942e6ef8789920cf4/src/main/java/org/codehaus/groovy/runtime/memoize/CommonCache.java#L67
This creates a CommonCache where accessOrder is set to true and then any get call on the underlying LinkedHashMap can cause a write change, not covered  appropriately by the checks.
[~sunlan] This looks like a bigger change will be required to fix this

> ConcurrentCommonCache causes memory leaks.
> ------------------------------------------
>
>                 Key: GROOVY-11271
>                 URL: https://issues.apache.org/jira/browse/GROOVY-11271
>             Project: Groovy
>          Issue Type: Bug
>          Components: ast builder
>    Affects Versions: 4.0.7
>            Reporter: cong yang
>            Priority: Critical
>
> ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a thread-safe data structure. However, CommonCache uses the underlying LinkedHashMap, which causes conflicts when using the LRU algorithm because the LinkedHashMap.get method modifies the internal linked list. This conflicts with the read lock used by the get method in ConcurrentCommonCache when multiple threads access it. Due to multithreading conflicts, the maximum cache size of 64 becomes ineffective, ultimately causing memory leaks. Additionally, we have already encountered memory leaks in our production environment.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)