Android线程池疑问：切换Activity时是否自动关闭及内存泄漏问题

Great questions—threading in Android gets really nuanced when tied to component lifecycles, so let’s unpack each part clearly:

1. Can other parts of the app access the non-static ExecutorService after leaving the Activity? #

It depends entirely on references:

• If the thread pool is a non-public member variable of your Activity, other components can only access it if they hold a strong reference to the Activity instance itself. If the Activity is destroyed and no other components reference it, the thread pool becomes unreachable (unless the threads inside it keep it alive—more on that below).
• If you’ve marked the thread pool as public, any component with a reference to your Activity instance can call methods on it. But holding an Activity reference after the component is destroyed is a common source of memory leaks, so this isn’t a practice I’d recommend.

2. Will "zombie threads" or memory leaks occur? #

Absolutely, if you don’t manage the thread pool properly:

• Memory leaks: If your thread pool (or the threads running inside it) holds a reference to the Activity (e.g., accessing this, a View, or Activity Context), the Activity can’t be garbage-collected even after onDestroy() is called. The thread pool will keep the Activity instance alive, wasting memory.
• Zombie-like thread behavior: Core threads in an ExecutorService (configured via ThreadPoolExecutor) stay alive indefinitely waiting for new tasks unless you call shutdown() or shutdownNow(). Even if the Activity is gone, these threads will keep running in the background, consuming system resources. Non-core threads will time out after an idle period, but core threads stick around. If these threads aren’t doing useful work, they’re essentially "zombies" wasting memory and CPU cycles.

3. If the thread pool is public and not shut down, can it still be accessed? #

Only if something still holds a reference to the Activity instance that owns it:

• If another component (like a Service, Fragment, or singleton) keeps a strong reference to your Activity, you can still access the public thread pool via that Activity instance. But again, this is risky because it keeps the Activity from being GC’d, leading to leaks.
• If the Activity instance is properly garbage-collected (no other references), the thread pool becomes unreachable—but the threads inside it might still be running (as core threads don’t shut down automatically). At that point, you can’t access the thread pool anymore, but it’s still wasting resources until the app process is killed.

Pro Tips for Safer Threading in Android #

• Always shut down your ExecutorService in onDestroy() (or onPause() if you don’t want background work continuing when the Activity is hidden) using shutdown() (graceful) or shutdownNow() (immediate).
• Consider using ViewModel to hold your thread pool instead of the Activity directly—ViewModel survives configuration changes (like screen rotations) and is only cleared when the Activity is permanently destroyed, reducing leak risks.
• For modern Android development, Kotlin Coroutines with lifecycle-aware scopes (like lifecycleScope or viewModelScope) are far easier to manage than raw ExecutorService—they automatically cancel work when the component is destroyed, eliminating most leak risks.

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