Can DefaultThreadContextMap be modified to avoid creating a new instance with each update?

[wang-qijia]

If the client calls MDC.put() 10 times, the current implementation creates 10 maps, resulting in frequent memory allocations. Is it possible to modify this so that put does not create a new map, and enhance getImmutableMapOrNull to return a decorated immutable version of the original map?

[ppkarwasz]

Hi @wang-qijia,

The DefaultThreadContextMap is (and always has been) a copy-on-write structure, which is useful if you need to move it from thread to thread.

If you want to limit the number of allocations, you can use methods such as ThreadContext.putAll().

If you want to remove the allocation entirely and you are not using a Servlet Container, you can switch to a garbage-free implementation as described in garbage-free logging by setting the log4j2.threadContextMap Log4j property to GarbageFree (or org.apache.logging.log4j.spi.GarbageFreeSortedArrayThreadContextMap if you are using Log4j 2.23.1 or an earlier version).

Note: The garbage-free ThreadContextMap is not always the best solution, that is why it is not the default one. What kind of application are you developing? Is being garbage-free important for you application? Garbage-free implementations always come at the cost of an increased memory usage.

[wang-qijia]

Hi @ppkarwasz
Thank you for your participation in the discussion.

The use case is to populate the MDC context into logs, and modifying the specific scenario using ThreadContext.putAll() would have a high cost. The described scenario can be achieved through other means, and as I understand it, it does not rely on a copy-on-write structure.

[ppkarwasz]

Yes, the easiest solution for you is to switch to a garbage-free ThreadContextMap.

ThreadContextMap is one of the most update interfaces in Log4j API. Adapting DefaultThreadContextMap in such a way that it:

• does not create memory leaks in Servlet environments (i.e. it can only store JRE classes in ThreadLocals),
• it is mutable,
• yet, it does not require a copy operation, when it is transfered to an asynchronous thread for logging.

is IMHO a highly non-trivial operation.

[vy]

@wang-qijia, I tend to agree with you. I think the default Thread Context implementation can (and should?) do better – see my comments here. I intend to submit a PR to improve the situation.

[wang-qijia]

Hi @vy
Thank you for your participation in the discussion.

Has there been any progress on this? Do you still need my help?

[vy]

@wang-qijia, thanks for asking, not needed at this point.