Original: Taste of Little Sister (wechat official ID: XjjDog), welcome to share, please reserve the source. Any reprint that does not retain this statement is plagiarism.

Java processes suddenly disappear, there is no information about them in the log, and they simply evaporate. Log, OOM some configuration parameters, not useful at all.

Don’t panic. Processes have no soul. A restart will make these programs come alive again.

The problems are the ones that restart can’t solve, and murphy’s Law operates in the background.

Who killed the beloved Java process?

Don’t be too cruel. At least let the process say something before you die. This short article will analyze several common Java process disappearance mysteries and leave you in peace.

They may:

  • Being judged by the operating system
  • Executed the God function and was buried by his teammates
  • The wrong startup mode is used
  • The log system is incorrectly configured

1. Being judged by the operating system

More than one of my friends has encountered the following problem: my Java process has disappeared, leaving nothing behind.

According to? Is it because of too much love and too many partners?

This is a very interesting and skillful problem.

Run the dmesg command and you will most likely see your process crash message lying dead.

In order to see when it happened, we habitually add the parameter T

dmesg -T
Copy the code

Obviously is the operating system to see your process is not pleasing to the eye, to Kill.

This phenomenon is related to Linux memory management.

Since Linux uses virtual memory allocation, the JVM’s code, libraries, heaps, and stacks consume memory, but allocated memory that is not actually accessed does not count as physical pages are not actually allocated to it.

You use more and more memory as you use it. The first protective wall is SWAP; When SWAP is ready, it tries to free the cache. When both are depleted, the killer emerges. Oom Killer will pop up when the system runs out of memory and selectively kill processes to free up some memory.

So our Java process is “terminated” by the operating system, and the JVM doesn’t even have a last word. This information can only be found in the operating system logs.

The first way to solve this problem is not to be greedy. For example, on an 8GB machine, you allocate a full 7.5GB to the JVM. When the operating system runs out of memory, your JVM can fall prey to an Oom-killer.

However, you can keep the process from being judged by the following command.

echo -17 > /proc/[PID]/oom_adj
Copy the code

This is because the oom_adj file, which is the weight of the process killed by oom killer, is usually somewhere between [-17,15]. The higher the weight, the more likely it is to be selected by OOM Killer.

Once you do this, your Java processes are privileged and can ignore the rules.

2. The God function is executed

Xjjdog’s assessment of this function is that it is better to not know it than to know it.

Don’t look at me. That’s you, System. Exit.

This function is dangerous, it will force the termination of our application and leave nothing behind. You should scan your code to make sure such logic does not exist.

Trust me, you don’t have the need to use procedural judgment to immediately terminate a process, especially in business systems. If there is, the probability is unreasonable. Unless you’re using Java as a script.

This function is a very advanced pothole skill, especially in applications like Android. The application crashes, and you can’t figure out why, even if you do ShutdownHook.

When using the exit function, always be kind.

Of course, we’re not helpless. The following code prevents exit from executing. God’s hand, too, has been snapped back.

import java.security.Permission;

public class S {
    private static class ExitTrappedException extends SecurityException {}private static void forbidSystemExitCall(a) {
        final SecurityManager securityManager = new SecurityManager() {
            public void checkPermission(Permission permission) {
                if (permission.getName().startsWith("exitVM")) {
                    throw newExitTrappedException(); }}}; System.setSecurityManager(securityManager); }private static void enableSystemExitCall(a) {
        System.setSecurityManager(null);
    }
    public static void main(String[] args) {
        forbidSystemExitCall();
        try {
            System.exit(0);
        }catch (Exception ex){
            ex.printStackTrace();
        }
        System.out.println("Thanks Xjjjdog, I can still execute."); }}Copy the code

If you can’t find the cause of the abnormal termination after all your efforts, try hanging up this code. It could be a lifesaver.

3. Incorrect startup mode

One of the most elementary, common, and often common causes of application death is the wrong way to start a Java program.

Many students are not very familiar with Linux, use XShell login, call the following command to start.

java com.cn.AA &
Copy the code

The student had the sense to use ampersand at the end to expect the process to run in the background. Unfortunately, in many cases, as the XShell Tab closes or waits for a timeout, subsequent Java processes stop altogether, which can be confusing.

The correct way to start is to use the nohup keyword, or to block other, longer-lived processes (such as docker).

nohup java com.cn.AA &
Copy the code

So when you log on to a terminal TTY, make sure you know who the parent process is currently executing. You are probably the ancestor of all the processes that will run next.

4. The log configuration is incorrect

If none of the above is the case, it is likely that the logging framework in your project is incorrectly configured. There are so many logging frameworks and configurations in Java that you can easily stumble. Even if you are using SpringBoot, there will be boot problems due to package dependencies.

Log configuration error + exception, of course, nothing is left.

The dependency tree can be moved to a log file for analysis using the following command.

mvn dependency:tree > dep.log
Copy the code

If you are a SpringBoot project, you can add some code to the main class.

public static void main(String[] args) {
		try {
			SpringApplication.run(LinkpowerDtulockApplication.class, args);
		} catch(Exception e) { System.out.println(e); }}Copy the code

That way, if there’s anything out of the ordinary, we can find it early.

End

In addition, there are some strange reasons. For example, the disk is full, the handle is not enough, these situations are very subtle, you need to control the precise details of the system.

The quiet death of processes often makes troubleshooting more difficult.

Usually, we use “kill-15” instead of “kill-9” when shutting down a service to give it a breather before it dies. But it doesn’t always work, because the program never gets a chance to say anything, and something higher prevents it. Java processes die suddenly, we have to find other means.

Xjjdog is a public account that doesn’t allow programmers to get sidetracked. Focus on infrastructure and Linux. Ten years architecture, ten billion daily flow, and you discuss the world of high concurrency, give you a different taste. My personal wechat xjjdog0, welcome to add friends, further communication.

Xjjdoc.cn has a detailed classification of 200+ original articles, making it easier to read. Welcome to collect.