未指定fallbackMethod的@HystrixCommand注解有什么作用？

Great question! Let's break down exactly what your @HystrixCommand is doing without a fallbackMethod, and when this setup makes sense.

What @HystrixCommand does even without a fallback #

The core purpose of Hystrix is isolation and circuit breaking—and these features work fully even if you don't define a fallback method. Let's tie this directly to your code:

• Thread Pool Isolation: Your annotation specifies threadPoolKey = "addressSearchPool", which means all executions of getAddressById() run in a dedicated thread pool. If your database starts having issues (like slow queries, connection timeouts, or pool exhaustion), this isolated pool prevents those problems from spilling over to other parts of your app. Other business logic won't get blocked or starved of threads because this method's failures are contained.

• Circuit Breaking: Hystrix monitors the failure rate of your getAddressById() method. Every time you throw MyCustomException (from a Sql2oException) or Hystrix hits a timeout, it counts as a failure. When the failure rate crosses the default threshold (50% of requests failing in 5 seconds, with at least 20 requests), the circuit "opens". For the next 5 seconds, Hystrix won't even attempt to call your method—it'll immediately throw a HystrixRuntimeException instead. This stops your app from hammering a broken dependency, giving it time to recover.

The groupKey and commandKey you set are still useful too: they help organize metrics, monitoring, and configuration for this specific command, making it easier to track performance or tweak Hystrix settings later.

When to use @HystrixCommand without a fallback method #

There are plenty of scenarios where skipping a fallback is the right call:

• Fast failure for better user experience: If failing to fetch an address is a clear error that the user needs to know about immediately (e.g., "We can't load your shipping address right now"), letting the exception bubble up to your controller or frontend is better than returning a stale/empty response. Users get clear feedback instead of waiting for a timeout.

• Simplify code for non-critical paths: If this address lookup is a secondary feature (like displaying optional user location data), your main business logic can just handle the exception gracefully (e.g., skip showing the address) without needing a separate fallback method. This keeps your code cleaner.

• Centralized exception handling: You might already have a global exception handler (like a Spring @ControllerAdvice) that catches MyCustomException or HystrixRuntimeException to log errors, send alerts, or return standardized error responses. In this case, a fallback method would be redundant—your existing error handling pipeline takes care of it.

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