Log4j2 has built-in Garbage-free (free garbage) mode, which can reuse objects and buffers, reduce garbage objects generated during logging, avoid GC recycling by the JVM, and thus improve application performance and response speed. The following is based on the 2.24.3 version of Log4j2, and objectively, truthfully and comprehensively introduces the Garbage-free garbage collection model, and summarizes its characteristics and application scenarios.
Let’s talk about the conclusion first:Log4j2's Garbage-free garbage collection mode has extremely limited support and applicable scenarios in actual use, and is of little significance. It is not recommended to enable it.
1. How to enable it
By default, Log4j2 decides whether to enable Garbage-free running mode based on whether the application is of web type (by determining whether the Servlet class is included in the classpath). If it is a web application and is not enabled, the attribute values and the attribute values are true and false respectively; otherwise, the two attribute values can be set to false and true, and the Garbage-free mode is forced to be turned on.
In a web application, if the ThreadLocal variable holds a non-JDK class and the web application is uninstalled, the thread pool of the application server continues to reference these variables, which may lead to an application memory leak. Therefore, to avoid memory leaks, web applications do not turn on Garbage-free mode by default. Web applications can enable this mode by force specifying =true. In addition, if you use thread context fields (such as MDC), you need to set the property to true.
It is recommended to place the above configuration properties in the file under the classpath (usually src/main/resources/). This configuration method can be overwritten by JVM variables, system environment variables, and encoding.
2. Supporting requirements
After enabling Garbage-free mode (the property value is set to true), you need to use Layouts, Appenders and Filters that support Garbage-free, and use the API reasonably to ensure that the mode is truly effective.
1. Supported Layout
(1) The three layouts are supported by conditions: GelfLayout, JsonTemplateLayout and PatternLayout, but the commonly used CsvLayout does not support.
(2) The above three types of Layouts are not fully supported. If a parameter, configuration, or method that does not support Garbage-free is used, it will cause the Layout to not support Garbage-free. For example, outputting fields such as Exception, Method, Line, Location, Class, File, etc. in PatternLayout will make the Layout not support Garbage-free.
2. Supported Appenders
(1) ConsoleAppender and file class Appender, such as FileAppender, MemoryMappedFileAppender, RandomAccessFileAppender, RollingFileAppender (non-rotating period), and RollingRandomAccessFileAppender (non-rotating period).
(2) Most Appenders involving external IO (network, database, message queue, etc.) are not supported, such as JDBCAppender, KafkaAppender, etc.
(3) The above conclusions are only derived from official documents and have not been tested in detail. To summarize Layout's experience, it is recommended to carefully refer to each Appender document to determine whether there are specific restrictions.
3. Supported Filters
(1)CompositeFilter, DynamicThresholdFilter, LevelRangeFilter, MapFilter, MarkerFilter, StructuredDataFilter, ThreadContextMapFilter, ThresholdFilter and TimeFilter are all supported.
(2) The above conclusions are only derived from official documents and have not been tested in detail. To summarize Layout's experience, it is recommended to carefully refer to each Appender document to determine whether there are specific restrictions.
4. Other situations
(1) If NDC (Nested Diagnostic Context) is used, Garbage mode cannot be supported.
(2) Asynchronous log (AsyncLogger) If the default timeout waiting policy is used, Garbage mode is supported.
(3) From the test situation, even if the Layout, Appender and Filter used all support Garbage mode, if the logger output content package does not support Garbage mode fields, the Garbage mode will not be able to be used in the end.
3. Strong recommendation
In actual projects, even if the application enables Garbage mode, it may not be actually enabled due to various usage restrictions and configuration requirements. It is strongly recommended to use JMH to pressure the corresponding log configuration and add the "prof gc" parameter to verify the recycling of GC, so as to determine whether the log configuration truly supports Garbage mode.
4. Performance comparison
Below we will use the same performance test benchmark to force the Garbage mode to turn on or off by configuring the parameters to determine the performance help of this mode.
1. Test benchmarks
(1) Hardware: Windows notebook, configured as I5-1350P CPU, 32G DDR5 5200 memory, and Samsung MZVL4512HBLU-00BLL 512G SSD (sequential write speed is 2430MB/s).
(2) Software: Based on JDK 1.8.171, using version 1.37 JMH and version 2.24.3 Log4j2.
(3) Configuration: Use FileAppender and its default configuration (append and immediateFlush are true), and use synchronous Logger for stress testing.
(4) Referring to daily usage, output a fixed string with a length of 100, and the layout of the log PatternLayout is: "% d {yyyy-MM-dd HH:mm:} %-5level %pid % t - % msg % n" .
(5) Add a configuration file under classpath and enable or turn off Garbage-free mode through the configuration item.
2. Log4j2 configuration file
<?xml version="1.0" encoding="UTF-8"?>
<Configuration name="log4j2AppenderTest" status="error">
<Properties>
<Property name="">
%d{yyyy-MM-dd HH:mm:} %-5level %pid %t - %msg %n
</Property>
</Properties>
<Appenders>
<Console name="Console">
<PatternLayout pattern="${}"/>
</Console>
<File name="File"
fileName="log/">
<PatternLayout pattern="${}"/>
</File>
</Appenders>
<Loggers>
<Root level="debug">
<AppenderRef ref="Console" />
</Root>
<Logger name="FileLogger" level="debug" additivity="false">
<AppenderRef ref="File" />
</Logger>
</Configuration>
3. JMH pressure test code
@State()
public class Log4J2FileAppenderBenchmark {
static Logger fileLogger;
int delFilesCount = 0;
@Setup()
public void setUp() throws Exception {
("", "");
fileLogger = ("FileLogger");
}
@TearDown
public void tearDown() {
("");
}
@BenchmarkMode()
@OutputTimeUnit()
@Benchmark
public void fileLogger() {
(Const.MSG_HAVE_100_CHARS);
}
}
4. JMH Parameters
The parameters executed by JMH are:-jvmArgs "-Xmx512m -Xms512m" -f 2 -t 4 -w 10 -wi 2 -r 30 -i 2 -to 300 -prof gc, that is, set the JVM parameter to -Xmx512m -Xms512m (the maximum and minimum heap memory are 512MB), use 2 forks (-f 2), and each fork uses 4 threads (-t 4), and runs each time during the warm-up phase. 10 seconds (-w 10), warm-up iterations 2 times (-wi 2), formal test runs for 30 seconds (-r 30), formal test iterations 2 times (-i 2), timeout is 300 seconds (- to 300), and enable GC performance analysis (-prof gc).
5. Test results
| type | Average throughput | Memory allocation rate (MB/sec) | Number of garbage collections |
|---|---|---|---|
| Garbage-free mode | 137.1 ops/ms | 10 MB/sec | 0 |
| Non-Garbage-free mode | 135.5 ops/ms | 18.8 MB/sec | 18 |
6. Test summary
(1) Since many PatternLayout parameters do not support garbage collection mode, the above PatternLayout configuration parameters are slightly simple. Under the same configuration, after enabling Garbage-free mode, the memory allocation amount drops significantly, and there is no GC recycling and time-consuming, but There was no significant improvement in throughput.
(2) In addition, other tests have found that the more the parameters without garbage collection mode are not supported, the more memory is occupied, such as the class, method, number of rows and complete exception stack information where the log is located.
5. Summary
In daily research and development, we mainly use Log4j2 for web development, and the Garbage-free mode is not enabled by default. If enabled forcibly, if used improperly, memory leakage may occur. Even if it is forced to be enabled, when used, all types of log output fields must contain basic fields such as classes, methods, row counts and complete exception stacks that generate the log. These fields do not support the Garbage-free mode, and will still generate garbage collection. Finally, Really enable this mode. So I think,Log4j2's Garbage-free garbage collection mode has extremely limited support and applicable scenarios in actual use, and is of little significance. It is not recommended to enable it.
6. Reference documents
（1） garbagefree