BLOCKING_EXECUTOR in ExecutorsRegistrar uses unbounded CachedThreadPool — causes 68+ threads on low-memory devices
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 52/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Área
- mobile, performance
Línea de trabajo
Comienza en firebase-common/.../concurrent/ExecutorsRegistrar.java e inspecciona cómo se crea y se utiliza BLOCKING_EXECUTOR. Compara las opciones de ThreadPoolExecutor acotado y LinkedBlockingQueue descritas en el issue, y después reproduce el escenario de poca memoria o inspecciona los volcados de hilos. Se considera terminado cuando la creación de hilos de bloqueo está acotada, mientras que la eliminación de hilos inactivos y el comportamiento del executor siguen siendo adecuados.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Description
ExecutorsRegistrar.BLOCKING_EXECUTOR uses Executors.newCachedThreadPool() with no upper bound on thread creation:
// firebase-common/.../concurrent/ExecutorsRegistrar.java
static final Lazy<ScheduledExecutorService> BLOCKING_EXECUTOR =
new Lazy<>(
() ->
scheduled(
Executors.newCachedThreadPool(
factory("Firebase Blocking", ...))));
On low-end Android devices (2GB RAM, 2 CPU cores), this creates 68+ "Firebase Blocking Thread" instances during normal app usage. Each thread consumes ~1MB of stack space, contributing to memory pressure that triggers the low memory killer (lmkd).
Environment
- Firebase product: firebase-messaging 25.0.1 (only Firebase product in use;
BLOCKING_EXECUTORcomes from the transitivefirebase-commondependency) - Device: 2GB RAM / 2-core CPU (emulator configured to simulate low-end Android Go devices)
- Android version: API 34
Evidence
Thread dump captured via Thread.getAllStackTraces() shows 68 threads named "Firebase Blocking Thread #0" through "Firebase Blocking Thread #67", all in TIMED_WAITING state:
"Firebase Blocking Thread #0" TIMED_WAITING
"Firebase Blocking Thread #1" TIMED_WAITING
...
"Firebase Blocking Thread #67" TIMED_WAITING
Shortly after, the process was killed by lmkd:
lowmemorykiller: reason: low watermark is breached and swap is low (276kB < 151960kB)
ActivityManager: Process has died: fg TOP
The app was the foreground TOP process and was still killed due to system-wide memory exhaustion.
Comparison
On a higher-spec emulator (4+ cores, more RAM), the same executor creates ~37 "Firebase Blocking Thread" instances. The slower CPU on the 2GB device means tasks take longer to complete, so more threads pile up before they can be reused — the exact scenario where unbounded pools are most dangerous.
Suggested fix
Replace Executors.newCachedThreadPool() with a bounded ThreadPoolExecutor in ExecutorsRegistrar.BLOCKING_EXECUTOR:
static final Lazy<ScheduledExecutorService> BLOCKING_EXECUTOR =
new Lazy<>(
() ->
scheduled(
new ThreadPoolExecutor(
0,
Math.max(4, Runtime.getRuntime().availableProcessors()),
60L, TimeUnit.SECONDS,
new SynchronousQueue<>(),
factory("Firebase Blocking", ...))));
This caps thread creation while preserving the same idle-thread reaping behavior. A LinkedBlockingQueue alternative would allow tasks to queue safely when all threads are busy.
- Lenguaje dominante
- Java
- Estrellas
- 2.6k
- Forks
- 733
- Merge medio
- 2 d 15 h
- PR fusionados (30 d)
- 72
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de firebase/firebase-android-sdk
-
api: remoteconfig
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
firebase/firebase-android-sdk#8827 ·
Los mantenedores suelen responder en 1 día
-
Crashlytics plugin writes build ID lists in directory listing order, so APKs can differ between machinesPosiblemente ocupada @mrober la tomó hace 8 días. Abiertoapi: crashlytics
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
firebase/firebase-android-sdk#8789 · 1 comentario · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
api: auth
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
firebase/firebase-android-sdk#8505 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 15/100
firebase/firebase-android-sdk#8835 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
firebase/firebase-android-sdk#8832 ·
Los mantenedores suelen responder en 1 día
Todos los issues de firebase/firebase-android-sdk
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
Los mantenedores suelen responder en 1 día
-
RIS export splits an organization name containing “and” into multiple authorsPosiblemente ocupada @Gautam-aman la tomó hoy. Abiertostatus: needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
JabRef/jabref#17821 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
FailureContext.java rounds down thresholds in lastedAtLeast()Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día