BLOCKING_EXECUTOR in ExecutorsRegistrar uses unbounded CachedThreadPool — causes 68+ threads on low-memory devices
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 52/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Lĩnh vực
- mobile, performance
Hướng nghiên cứu
Bắt đầu trong firebase-common/.../concurrent/ExecutorsRegistrar.java và kiểm tra cách BLOCKING_EXECUTOR được tạo và sử dụng. So sánh các tùy chọn ThreadPoolExecutor có giới hạn và LinkedBlockingQueue được mô tả trong issue, sau đó tái hiện tình huống bộ nhớ thấp hoặc kiểm tra các thread dump. Được xem là hoàn tất khi việc tạo các blocking thread được giới hạn, đồng thời việc thu hồi các thread nhàn rỗi và hành vi của executor vẫn phù hợp.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Java
- Star
- 2.6k
- Fork
- 733
- Merge trung bình
- 2 ngày 15 giờ
- Pull request đã merge (30 ngày)
- 72
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của firebase/firebase-android-sdk
-
api: remoteconfig
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
firebase/firebase-android-sdk#8827 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Crashlytics plugin writes build ID lists in directory listing order, so APKs can differ between machinesCó thể đã có người làm @mrober đã nhận 8 ngày trước. Đang mởapi: crashlytics
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
firebase/firebase-android-sdk#8789 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
api: auth
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
firebase/firebase-android-sdk#8505 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 15/100
firebase/firebase-android-sdk#8835 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
firebase/firebase-android-sdk#8832 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của firebase/firebase-android-sdk
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 80/100
Maintainer thường phản hồi trong vòng 1 ngày
-
RIS export splits an organization name containing “and” into multiple authorsCó thể đã có người làm @Gautam-aman đã nhận hôm nay. Đang mởstatus: needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
JabRef/jabref#17821 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
FailureContext.java rounds down thresholds in lastedAtLeast()Có thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 1 ngày