如何解决START_STICKY启动的Service出现重复运行实例的问题

问题根因 #

你观察到的「双Service实例」本质是Service销毁时未主动关闭后台线程导致的资源残留：Android系统同一进程内只会维护一个同类型Service的唯一实例，你看到两个hash的日志输出，是旧Service实例关联的ScheduledExecutorService核心线程未随Service销毁而停止，仍持有旧Service引用持续打印日志导致的假象。

日志疑问解答 #

杀死进程时为什么onCreate调用后会触发onDestroy？
你杀死应用主进程时，系统首先触发原Service的onUnbind回调，之后START_STICKY机制触发系统尝试重启Service，短暂创建了hash为9d89377的新实例，但此时主进程正在被系统回收，刚创建的Service实例立刻被销毁触发onDestroy，但你未关闭的线程池仍在运行，所以后续仍会打印该hash的日志。

可选解决方案 #

方案1：绑定后台已运行的旧Service实例 #

该方案适合需要Service始终在后台独立运行、不随主进程销毁的场景：

• 在AndroidManifest.xml中给Service配置固定独立进程，避免随主进程销毁：

  <service
      android:name=".YourService"
      android:process=":service_remote" />
  

• 跨进程绑定需要改用AIDL实现Binder通信，不能直接使用本地Binder，主进程重启后调用bindService会直接连接到独立进程中已运行的Service实例，不会创建新实例。
• 若不需要跨进程，仅需在主进程运行Service，直接使用方案2即可。

方案2：应用重启时销毁旧Service实例 #

该方案实现更简单，适合不需要Service跨进程运行的场景：

1. 先修复线程泄漏问题，在Service的onDestroy中主动关闭线程池：

   @Override
   public void onDestroy() {
       super.onDestroy();
       if (scheduleTaskExecutor != null && !scheduleTaskExecutor.isShutdown()) {
           scheduleTaskExecutor.shutdownNow();
       }
   }
   

2. 优化Activity启动逻辑：先停止已存在的Service，再执行绑定，同时移除不必要的startService调用（BIND_AUTO_CREATE会自动创建不存在的Service）：

   Intent serviceIntent = new Intent(this, Service.class);
   // 先停止所有旧Service实例，销毁残留资源
   stopService(serviceIntent);
   // 绑定新的Service实例
   bindService(serviceIntent, serviceConnection, Context.BIND_AUTO_CREATE);
   

3. 可选调整：如果不需要Service在进程被杀死后自动重启，可以将onStartCommand返回值改为START_NOT_STICKY，避免系统自动重启产生残留实例。

内容的提问来源于stack exchange，提问作者Spiros