ppkarwasz commented on issue #3569: URL: https://github.com/apache/logging-log4j2/issues/3569#issuecomment-2753465403
> Based on these observations, I have the some questions: > > * Could the difference between `DefaultThreadContextMap` and `CopyOnWriteSortedArrayThreadContextMap` be the reason I’m seeing an increase in memory usage? Could you briefly explain the differences between these two classes? I’ve noticed they affect memory usage, and I’d like to understand why. Up to version `2.23.x`: - `DefaultThreadContextMap` was an implementation of `ThreadContextMap` basically equivalent to `ThreadLocal<HashMap>`. Since it only bound classes from the bootstrap classloader to threads, it was safe to use in web applications without memory leaks. `DefaultThreadContextMap` was also a _copy-on-write_ implementation, which allowed us to transfer the maps returned by it to other threads. - `CopyOnWriteSortedArrayThreadContextMap` was a more performant _copy-on-write_ implementation, but it bound Log4j classes to threads, so it wasn't safe to use in web applications. In version `2.24.0` a version of `DefaultThreadContextMap` was introduced that was both webapp-safe and fast (see #2330). The package-private `CopyOnWriteSortedArrayThreadContextMap` was removed. Since both implementations use **immutable** objects `RingBufferLogEvent` will not keep references to them: https://github.com/apache/logging-log4j2/blob/93afabcd3817738454e38f4cf65dfa84268a2eb1/log4j-core/src/main/java/org/apache/logging/log4j/core/async/RingBufferLogEvent.java#L451-L459 Your log events retain instances of `SortedArrayStringMap`, which seems to indicate that `GarbageFreeSortedArrayThreadContextMap` is used instead. In code you can check it with `ProviderUtil.getProvider().getThreadContextMapInstance()` (since `2.24.0`), while in previous versions with `ThreadContext.getThreadContextMap()` (which returns `null` for the default map). > * Under the same configuration (not a web app), when `log4j2.garbagefreeThreadContextMap` isn’t enabled, memory usage in 2.24.3 seems less stable compared to 2.23.1. Is this an expected change? The use of `DefaultThreadContextMap` will generate a little bit more temporary objects than `CopyOnWriteSortedArrayThreadContextMap`, in particular instances of `JdkMapAdapterStringMap`. These should however have no influence on the amount of memory retained in the long term. Right now, my best bet on why your system behaves the way he does is that `GarbageFreeSortedArrayThreadContextMap` is somehow used. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
