Why Using kill -9 to Stop a Java Service Can Cost You Your Job

Understanding kill -9

The Linux kill command sends signals to processes. By default it sends SIGTERM (15) to request termination; if the process does not stop, SIGKILL (9) can be used to force termination.

Problems caused by kill -9

Because kill -9 aborts a process abruptly, it can leave resources in an inconsistent state. For example, in a money‑transfer scenario using MyISAM tables, killing the process after debiting account A but before crediting account B results in lost money, similar to a sudden power outage. Distributed transactions suffer the same risk.

Graceful shutdown process

A proper shutdown should follow four steps:

Stop accepting new requests and internal threads.

Check whether any threads are still running.

Wait for running threads to finish.

Stop the container.

Using kill -15

Sending SIGTERM (15) allows the JVM to interrupt sleeping threads. The article provides a simple controller that sleeps for 100 seconds:

@GetMapping("/test")
public String test(){
    log.info("test --- start");
    try { Thread.sleep(100000); } catch (InterruptedException e){ e.printStackTrace(); }
    log.info("test --- end");
    return "test";
}

When the process is killed with kill -15 <pid>, the log shows an InterruptedException from the sleep call, but the test --- end message is still printed because the thread decides when to stop.

Using ConfigurableApplicationContext.close()

Spring Boot can be stopped programmatically by obtaining the ConfigurableApplicationContext and calling close():

public void shutdown(){
    ConfigurableApplicationContext ctx = (ConfigurableApplicationContext) context;
    ctx.close();
}

The close() method removes the JVM shutdown hook and triggers the container shutdown.

Using Spring Boot Actuator

Adding the actuator starter and exposing the /shutdown endpoint enables a REST‑based graceful stop:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Configuration (application.yml):

management:
  endpoints:
    web:
      exposure:
        include: shutdown
  endpoint:
    shutdown:
      enabled: true

Calling POST /actuator/shutdown returns a friendly message and stops the service, as shown in the console logs.

Running custom code before shutdown

Annotating a method with @PreDestroy lets you execute backup or cleanup logic just before the container stops:

@Configuration
public class DataBackupConfig {
    @PreDestroy
    public void backData(){
        System.out.println("正在备份数据……");
    }
}

Elegant shutdown with a custom Tomcat connector

The article introduces ElegantShutdownConfig that pauses the Tomcat connector, shuts down the thread pool, and waits up to 10 seconds before forcing termination:

public class ElegantShutdownConfig implements TomcatConnectorCustomizer, ApplicationListener<ContextClosedEvent> {
    private volatile Connector connector;
    private final int waitTime = 10;
    @Override
    public void customize(Connector connector){ this.connector = connector; }
    @Override
    public void onApplicationEvent(ContextClosedEvent event){
        connector.pause();
        Executor executor = connector.getProtocolHandler().getExecutor();
        if (executor instanceof ThreadPoolExecutor){
            ThreadPoolExecutor pool = (ThreadPoolExecutor) executor;
            pool.shutdown();
            if (!pool.awaitTermination(waitTime, TimeUnit.SECONDS)){
                System.out.println("请尝试暴力关闭");
            }
        }
    }
}

Registering the bean in the Spring Boot main class and testing shows that the service stops without the earlier InterruptedException because the thread pool is given time to finish.

Key takeaways

Never use kill -9 on a running Java service; it can cause data loss and inconsistent state.

Prefer graceful termination via kill -15, ConfigurableApplicationContext.close(), Actuator’s shutdown endpoint, or a custom shutdown hook.

Use @PreDestroy to run backup or cleanup logic before the JVM exits.

When the service is shutting down, new requests are rejected, ensuring no partial processing.