Java 9 ServiceLoader运行时模块加载与替换技术咨询

Great question—let’s break this down step by step since Java 9’s module system adds some important nuances to how ServiceLoader and dynamic service management work.

Can you add service implementations after the app has started? #

Yes, but it’s not as straightforward as the pre-module ServiceLoader (which relied on classpath scanning). The default ServiceLoader loads services statically when your module initializes, but you can use dynamic module layers to load new service implementations at runtime:

1. Package your new service implementation as a standalone Java 9 module (with a module-info.java that declares provides YourServiceInterface with YourNewImpl;).
2. Use ModuleLayer to load this module’s JAR file into a new layer attached to your app’s existing module hierarchy.
3. Create a ServiceLoader instance tied to this new layer to discover the new service implementation.

Here’s a quick code snippet to illustrate this:

// Path to your new service JAR
Path newServiceJar = Paths.get("/path/to/new-algorithm-module.jar");

// Locate the new module
ModuleFinder moduleFinder = ModuleFinder.of(newServiceJar);

// Resolve the module against your app's existing module configuration
Configuration parentConfig = ModuleLayer.boot().configuration();
Configuration newModuleConfig = parentConfig.resolve(
    moduleFinder,
    ModuleFinder.of(), // No additional module sources needed
    Set.of("com.your.calculation.algorithm") // Name of the new module
);

// Create a new module layer with the new module
ModuleLayer newLayer = ModuleLayer.boot().defineModulesWithOneLoader(
    newModuleConfig,
    ClassLoader.getSystemClassLoader()
);

// Load the service from the new layer
ServiceLoader<CalculationAlgorithm> loader = ServiceLoader.load(newLayer, CalculationAlgorithm.class);
Optional<CalculationAlgorithm> newAlgorithm = loader.findFirst();

Once loaded, you can integrate this new implementation into your app’s logic.

Can you remove service implementations? #

Not natively at the JVM level—Java’s module system and class loader architecture don’t support unloading modules or classes reliably (unless you jump through complex hoops with custom class loaders and no lingering references).

That said, you can implement logical removal at the application level:

• Maintain a registry of active service implementations (e.g., an AtomicReference or a managed list).
• When you want to "remove" an implementation, mark it as inactive and stop routing requests to it.
• If the old implementation has no remaining references in your app, the garbage collector will eventually reclaim it (though this isn’t guaranteed immediately).

Dynamic algorithm replacement for your calculation app #

For your use case—swapping calculation algorithms without stopping the app—here’s a practical, module-compliant approach:

Step 1: Structure your modules properly #

• Define a service interface module (e.g., com.your.calculation.api) that declares the CalculationAlgorithm interface and uses uses CalculationAlgorithm; to indicate it consumes this service.
• Package each algorithm as a separate module (e.g., com.your.calculation.algorithm.v1, com.your.calculation.algorithm.v2) that declares provides CalculationAlgorithm with V1AlgorithmImpl; (or V2).

Step 2: Implement runtime switching logic #

• In your main app, use an AtomicReference to hold the currently active algorithm:

  private static final AtomicReference<CalculationAlgorithm> ACTIVE_ALGORITHM = 
      new AtomicReference<>(loadDefaultAlgorithm());
  

• When you need to replace the algorithm:
  1. Load the new algorithm module using the ModuleLayer approach shown earlier.
  2. Validate the new implementation works (e.g., run a test calculation).
  3. Atomically update the ACTIVE_ALGORITHM reference to point to the new implementation.

Step 3: Jar replacement workflow #

When swapping algorithm JARs:

• Ensure the new JAR is a valid Java 9 module with the correct module-info.java declarations.
• Drop the new JAR into your app’s designated module directory (or any accessible path).
• Trigger your app’s "load new algorithm" logic (e.g., via an admin endpoint, CLI command, or file watcher that detects the new JAR).
• No need to stop the app—your code will start using the new algorithm immediately after the switch.

Key notes #

• Module dependencies: Make sure the new algorithm module doesn’t introduce conflicting dependencies with your existing app modules.
• Isolation: Using separate ModuleLayers keeps new implementations isolated from the rest of your app, reducing the risk of side effects.
• Cleanup: While you can’t unload old modules, ensuring no references to the old algorithm remain will let the GC clean up unused classes over time.

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