Static code analysis tools read the code just like the compiler and analyze it, but instead of compilation, they try to find errors or mistakes in it. Not the syntax errors. For that, we already have the Java compiler. Mistakes, such as using a loop variable outside a loop, which may be absolutely valid but is usually bad style and, many times, such usage comes from some simple mistakes. They also check that the code follows the styling rules that we set.
Static code analyzers help identify many small and obvious errors in the code. Sometimes, they are annoying, warning about something that may not be really a problem. In such a case, it is better to code the program a bit differently, not because we want the static code analysis to run without warning. We should never modify the code because of a tool. If we code something in such a way that it passes some quality check tool and not because it is better that way, then we are serving the tools instead of the tools serving us.
The reason to change the code to pass the code analysis is that it is very probable that the code is more readable to an average programmer if it does not violate the coding style. You or the other team members can be excellent programmers who understand the code very easily even if it uses some special construct. However, you cannot say that about all the programmers who will maintain your code in the future. The code lives a long life. I work with some programs that have been written 50 years ago. They are still running and maintained by young professionals around the age of 30. It means that they were not even born when the code was developed. It can easily happen that the person maintaining your code is not even born by the time you write the code. You cannot tell anything about their cleverness and coding practices. The best we can do is to prepare for the average and that is exactly what static code analysis tools are set for.
The checks that these tools perform are not hardwired into the tools. Some special language inside the tools describes the rules and they can be deleted, other rules can be added, and rules can be modified. This way, you can accommodate the coding standards of the enterprise you work for. The different rules can be categorized as cosmetic, minor, major, and critical. Cosmetic things are mainly warnings and we do not really care about them, even though it is nice to fix even these issues. Sometimes, these small things may signal some really big issue. We can set limits for the number of minor and major bugs before the check is declared as failing and also for the critical errors. In the last case, this limit is usually zero. If a coding error seems to be critical, then better not have any in the code.
The most frequently used tools are Checkstyle, FindBugs, and PMD. The execution of these tools is usually automated, and though they can be executed from the IDE or from the developer's command line, their main use is on the continuous integration (CI) server. During the build, these tools are configured on the CI server to run, and it can be configured such that the build should be broken if the static code analysis fails with some limit. Executing the static code analysis is usually the next step after compilation and unit test execution, and before the actual packaging.
The SonarQube tool (https://www.sonarqube.org/) is a special tool in addition to being a static code analysis tool. SonarQube maintains the history of the previous checks as well as supports unit test code coverage and can report the change of the quality over time. This way, you can see how the quality, coverage percentage, and number of different qualifications of code style errors have changed. Many times, you can see that when approaching the release date, the code quality decreases as people are in a rush. This is very bad because this is the time when most of the bugs should be eliminated. Having a statistic about the quality may help change the practice by seeing the trends before the quality, and thus the maintainability of the code gets out of hand.