Background: Mentor was cr someone else’s code when he found a code that printed a log

log.info("xxxxx {}",xxx.toString());
Copy the code

The info level is the same as the log level of the system. The toString() method will be executed. If the info level is debug, the toString() method will be executed, but the log will not be printed.

Depth:

When reviewing the code, I found that too many people used to connect the log directly with the “+” sign. This is a very bad habit.

In Logger, the logging methods are overloaded with forms that accept one, two or more values.[9] Occurrences of the simple pattern {} in the log message are replaced in turn with the values. This is simple to use yet provides a performance benefit when the values have expensive toString() methods. When logging is disabled at the DEBUG level, the logging framework does not need to evaluate the string representation of the values. In the following example, the values count or userAccountList only need to be evaluated when DEBUG is enabled; otherwise the overhead of the debug call is trivial.

private static final Logger LOG = LoggerFactory.getLogger(Wombat.class);
LOG.debug("There are now " + count + " user accounts: " + userAccountList); // slow
LOG.debug("There are now {} user accounts: {}", count, userAccountList);    // faster
123
Copy the code

As shown in the demo above, please choose the second writing method. Cause 1: The second use of placeholders executes the toString methods of count and userAccountlist only if the log level is DEBUG, and the first non-debug level executes as well. Reason 2: It’s more readable.

The first, whether debug or otherwise, executes the toString method of the input value, and the second only executes at the Debug level.

The second use of occupancy and string concatenation is implemented using StringBuilder(). Multi-character placeholders are more efficient. Specific choice depends on personal preference. Note that the number of placeholders is less than the number of arguments passed in. There is no error, there is a ordering problem when mapping arguments. This problem can be avoided by using the SonarLint plug-in for scanning. Here are some tips for printing a log

  1. Log printing level
level content
ERROR A serious mistake has occurred and must be dealt with immediately. This level of error is unacceptable on any system. For example, the null pointer is abnormal, the database is unavailable, and the critical path use case cannot continue.
WARN Subsequent processes will continue, but should be noted. I want to have two levels here: an obvious problem with a solution (e.g., “current data is not available, use cached data”), and potential problems and suggestions (e.g., “the program is running in development mode” or “the admin console password is not secure enough”). Applications can tolerate these messages, but they should be checked and fixed.
DEBUG Developer concerns. I’ll talk later about what should be recorded at this level.
TRACE More detailed information is only for use in the development phase. You may need to keep an eye on these messages for a while after the product launches, but these logs are only temporary and should eventually be turned off. It’s hard to tell the difference between DEBUG and TRACE, but if you add a line to a log and then delete it after development tests, the log should be TRACE.
  1. The semantics of log content should be clear to facilitate error troubleshooting. Generally, input and output parameters are printed when a method is requested or a remote call is made. Use placeholders for inbound and outbound parameters, and ToStringBuilder(non-reflective implementation) for string concatenation. DeepToString () for Arrays or collections printing;
  2. There is no need to print the log when an exception is thrown, because it will print the log repeatedly.
  3. Error (“Error Reading configuration file”,** e**); **
  4. Log readability needs to be considered, such as conversion of date format classes.

Refer to the blog

Refer to the blog