Making ServiceLoader usable: a provider factory

Java's ServiceLoader has two well-known limitations: it requires a no-arg constructor and provides no built-in selection mechanism. This post presents a provider factory pattern that addresses both. Instead of loading the service directly, you load a lightweight factory (ServiceProvider<S>) that carries an ID, a priority, and a supports() check. The real service is constructed inside create() with whatever constructor it needs. A generic ServiceRegistry loads all providers once into an immutable list sorted by priority, then exposes get(id, cfg) and getDefault(cfg) for selection. Caching is added as a decorator using ConcurrentHashMap, lifecycle reuses AutoCloseable, and cross-cutting concerns attach via a UnaryOperator post-processor. The pattern requires no dependencies beyond the JDK, works on both classpath and module path, and avoids dynamic proxies — making it GraalVM native-image friendly.

Nguồn: https://blog.frankel.ch/serviceloader-provider-factory. 8sync News chỉ tóm tắt và dẫn link; bản quyền nội dung thuộc tác giả và nguồn gốc.

Đề xuất cho bạn

Code Like A Girl2 Hot7 phút1 ngày trướcAI

Hibernate Turned 11,000 Records Into 50 Million Rows

Một tác vụ bulk-import xử lý 15.000 template giao dịch đã khiến hệ thống crash do lỗi Cartesian product của Hibernate. JPQL query dùng JOIN FETCH trên hai collection cùng lúc khiến Hibernate cross-join chúng, biến ~11.000 bản ghi thành 50 triệu dòng trong bộ nhớ. Lỗi này không lộ ra trong test nhỏ vì các collection được mapping dưới dạng Set thay vì List (lẽ ra phải ném MultipleBagFetchException khi khởi động). Giải pháp là tách query thành hai lần fetch riêng biệt, dùng @BatchSize để tải batch, và flush/clear session Hibernate định kỳ trong quá trình import lâu dài, giúp giảm 9 lần số dòng và cải thiện tốc độ xử lý lên 15 lần.

Lập trình viên nên đọc bài này để tránh rủi ro như biến vấn đề JOIN FETCH thành Cartesian product khổng lồ, gây sập ứng dụng do quá tải bộ nhớ trong các dự án bulk import lớn.