MDC (Mapped Diagnostic Context Mapped Diagnostic Context)
One of the design goals of Logback is to review and debug complex distributed applications. Most distributed systems in the real world need to handle multiple clients simultaneously. In a typical multithreaded distributed system, different threads handle different clients. A possible but bad way to differentiate logging output from different clients is to create new, independent loggers for each client. This technique increases the number of loggers and greatly increases the management overhead.
A lightweight technique is to uniquely stamp each record request from the client. Logback uses a variation of this technique in SLJ4J: Mapped Diagnostic Context (MDC).
In order to add a unique stamp to each request, the user puts context information into the MDC. The important parts of the MDC class are as follows, for more methods, please refer to the MDC javadocs documentation:
The MDC class has only static methods, and developers can put information into a diagnostic environment, and then use other logback components to obtain this information. MDC is managed on a per-thread basis. Child threads automatically inherit a copy of their parent's mapped diagnostic environment. Typically, when starting a service for a new client request, the developer inserts the appropriate contextual information into the MDC, such as client id, client IP address, request parameters, and so on. The Logback component automatically includes this information in each log entry.
The following program impleMDC demonstrates this basic principle.
Example: MDC Basic Usage
( logback-examples/src/main/java/chapters/mdc/ The 
main() method first associates the key "first" with the value "Dorothy" in the MDC. You can put any number of key/value pairs in the MDC. Same name The key will overwrite the value of the old key. The code then configures logback.
For the sake of brevity, we have ignored the code that configures logback with the configuration file simpleMDC.xml. Here is the relevant part of the configuration file:
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<layout>
<Pattern>%X{first} %X{last} - %m%n</Pattern>
</layout>
</appender>
Note the usage of "%X" in PatternLayout. "%X" is used twice, once for the key "first" and once for the key "last". The code first gets the logger corresponding to "SimpleMDC.class", then associates a value "Parker" with the key "last", then calls the logger twice with different messages, and finally sets the MDC to some other value and performs several logging requests.
Running SimpleMDC, output:
Dorothy Parker - Check enclosed.
Dorothy Parker - The most beautiful two words in English.
Richard Nixon - I am not a crook.
Richard Nixon - Attributed to the former US president. 17 Nov 1973.
The SimpleMDC program demonstrates how logback's layout can automatically output MDC information. Furthermore, the information placed in the MDC can be used multiple times by the logger.
The mapping diagnostic environment works best in client-server mode. Typically, multiple clients are handled by multiple threads of the server. Although the methods in MDC are static, MDC is managed on a per-thread basis, which allows each thread of the server to have its own independent MDC stamp. MDC operations, such as put() and get(), only act on the current thread and child threads of the current thread, and do not affect MDCs in other threads. Since the information of the MDC is managed on a per-thread basis, each thread has its own copy of the MDC. So when using MDC, developers don't need to worry about thread safety or synchronization, because MDC handles these issues transparently and safely.
MDC can be seen as a hash table bound to the current thread, to which key-value pairs can be added. Content contained in the MDC can be accessed by code executing in the same thread. Child threads of the current thread inherit the contents of the MDC in their parent thread. When logging is required, just get the required information from the MDC. The contents of the MDC are saved by the program when appropriate. For a Web application, this data is usually stored at the very beginning of the request being processed.