content
First, the idea package closes the test
Two, log4j and slf4j package conflict
3. The user.name configuration and the system environment variable name are invalid
Fourth, jvm memory alarm
Some problems are often encountered in daily work, and it will take a lot of time to solve them, but they will be forgotten over time. Here are a few questions that came up this week:
First, the idea package closes the test
This week the project is in the debugging stage. During the debugging process, the test data in the database table is often deleted or modified. It seriously affected the test progress. At first, it was suspected that some colleagues modified the data artificially. After several investigations, it was found that the unit test method in the code project will be automatically executed during the compilation and packaging process using the idea , and the unit test method has records in the database table. CRUD operations. Part of the carefully prepared test data is tampered with each time the maven package is executed. Solution: close the unit test when packaging, close the method, click on the maven panel of the idea , and click a lightning mark, as shown below:
Two, log4j and slf4j package conflict
The conflicting packages are log4j-over-slf4j.jar and slf4j-log4j12.jar , the phenomenon is that tomcat fails to start, and the error log content is:
java.lang.StackOverflowError
Caused by: java.lang.IllegalStateException: Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class path
From a daily point of view, log4j-over-slf4j.jar and slf4j-log4j12.jar conflict. Analysis of the cause of the conflict:
First look at slf4j-log4j12.jar (transfer to log4j log framework, forward process, official website: official website https://www.slf4j.org/manual.html#swapping )
slf4j is not a log framework, but a log printing specification. log4j is a log framework responsible for specific log printing (similar to the popular logback , which is said to have better performance than log4j ). Their relationship is somewhat similar to the relationship between the jvm specification and Hotspot , one is the specification and the other is the specific implementation.
Here slf4j is a specification that encapsulates various log printing specifications. For example, you can use placeholders to print logs: logger.error("{} Login successful, login time {}",userid , "2017-09-01") . The final specific log printing operation is handed over to log4j for processing.
At this time, slf4j-log4j12.jar needs to be introduced , and the dependencies are: slf4j-api.jar à slf4j-log4j12.jar à log4j.jar .
If one day you want to switch to the logback logging framework with better performance , just replace the slf4j-log4j12.jar package with logback .
Let's take a look at log4j-over-slf4j.jar ( log4j calls back to slf4j , reverse process, official website: https://www.slf4j.org/legacy.html )
Use log4j-over-slf4j to replace log4j , so that the logs output by the log4j interface will be routed to SLF4J through log4j-over-slf4j , so that even the system (including the third-party jar library used, such as dubbo ) can finally route the log to SLF4J , and then focus the output. This dependency is: log4j-over-slf4j.jar à slf4j-api.jar , it can be seen that this dependency is just the opposite of the above, resulting in infinite mutual recursive dependencies and eventually overflow.
refer to:
http://blog.csdn.net/kxcfzyk/article/details/38613861?utm_source=tuicool
http://blog.csdn.net/john1337/article/details/76152906
3. The user.name configuration and the system environment variable name are invalid
Well-meaning netizen sxp2558 found a bug in the process of SkySchedule ( http://moon-walker.iteye.com/blog/2386504 ) : when the author configures the username used for netty connection, the key configured in the properties file is "user. name" , the value configured in the code is "moon", but in actual use, the value obtained through the spring context Environment is the " host name " of the current server , which causes the SkySchedule client to fail to connect to the server successfully.
The root cause is: "user.name" is the default system constant, and the value configured in the properties will be overwritten, resulting in the " hostname " read instead of the user name configured in the properties file.
It has now been changed to "sky.user.name" , and the code has been submitted to github . Thanks again sxp2558 .
Fourth, jvm memory alarm
This week, the system to which the project belongs has several jvm memory alarms, and the memory usage exceeds 80% .
Firstly, the analysis system adopts the garbage collection algorithm: the ParNew collector used in the young generation and the Parallel Old collector used in the old generation are both parallel collectors, and the jdk version is 1.8 .
Looking at the GC situation, there is no full gc triggered , only a small amount of young GC , and the system access volume is not high. Preliminary analysis is that each time the young generation GC survives more objects, the objects accumulated in the old generation are increasing, and whether the full GC is triggered .
Solution:
1. You can write a timed task, call system.gc() to trigger full gc at 2:00 a.m. every night when the business is idle .
2. When the memory usage reaches a certain percentage, full GC is automatically triggered .
The first method, which needs to be re-launched, has not been adopted for the time being.
The second method is to use the CMS collector instead of the old generation. The CMS collector has a CMSInitiatingOccupancyFraction parameter, which can control the memory usage of the old generation when it reaches a certain ratio and trigger full GC automatically . Parallel collector did not find similar parameters. Colleagues finally changed the parameters to:
-XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=65
The specific meanings are: use cms garbage collector; enable defragmentation; perform a defragmentation after 5 full GCs ; automatically perform full GC when the old generation memory exceeds 65%
Since the CMS garbage collector is very sensitive to CPU requirements, after modifying the JVM parameters, it is necessary to further observe and decide whether to switch back to the Parallel garbage collector according to the situation.