Reflection is not automatically a performance problem. Repeated reflection in hot paths is.
That distinction matters because many systems waste time “removing reflection” broadly when the real problem is much narrower:
- repeated metadata lookup
- repeated accessibility work
- repeated reflective dispatch inside request paths
The right goal is not purity. It is to pay reflective costs once where possible and keep them out of the code that runs on every request.
Where Reflection Usually Hurts
Reflection tends to hurt in four places:
- method or field discovery on every request
- per-request annotation scanning
- reflective invocation inside tight loops
- startup scanning that is accidentally repeated at runtime
One-time reflective setup is often fine. Unbounded repetition is where CPU and allocation costs start becoming visible.
The First Move Is Usually Metadata Caching
If the code repeatedly discovers the same member information, cache it once.
public final class AccessorCache {
private final ConcurrentMap<Class<?>, MethodHandle> idGetters = new ConcurrentHashMap<>();
public String readId(Object target) {
try {
MethodHandle mh = idGetters.computeIfAbsent(target.getClass(), this::buildGetter);
return (String) mh.invoke(target);
} catch (Throwable t) {
throw new RuntimeException("Failed to read id", t);
}
}
private MethodHandle buildGetter(Class<?> type) {
try {
Method m = type.getMethod("id");
return MethodHandles.lookup().unreflect(m);
} catch (ReflectiveOperationException e) {
throw new IllegalArgumentException("No id() on " + type.getName(), e);
}
}
}
This changes the cost model:
- discovery happens once per class
- invocation becomes cheaper and more predictable
- request-time work gets simpler
That is often enough to solve the real problem.
Separate Startup Reflection From Request Reflection
A useful design question is:
Is this cost paid once at startup, or every time traffic hits the service?
Those are different problems.
- startup-heavy applications may care about classpath scanning and annotation indexing
- high-throughput services usually care about per-request dispatch cost
If you do not separate those two, you can easily optimize the wrong phase.
MethodHandle Is Often the Right Next Step
When reflection still shows up in a profiled hot path after caching, MethodHandle is often a better fit than repeated reflective invocation.
MethodHandle handle = MethodHandles.lookup()
.findVirtual(Order.class, "status", MethodType.methodType(String.class));
String status = (String) handle.invokeExact(order);
This is useful when:
- the call site is stable
- the signature is known
- the code path is hot enough to justify the change
It is much less useful when the problem is actually poor architecture or repeated metadata scanning elsewhere.
Sometimes Code Generation Is Better Than Reflection
If the contract is stable and performance-sensitive, generated accessors or mappers may be better than any reflective strategy.
That is especially true for:
- serialization paths
- mapping-heavy frameworks
- startup metadata registries
This is not because reflection is evil. It is because stable contracts often deserve direct code once the hotspot is proven.
A Good Example: Controller Argument Binding
Suppose a web layer currently:
- scans annotations for each request
- resolves parameter metadata repeatedly
- uses reflection to invoke handlers every time
A stronger design is:
- scan and validate controller metadata at startup
- build immutable handler descriptors
- cache parameter resolvers
- replace reflective hot-path calls with bound handles where it matters
That keeps flexibility while moving the expensive introspection out of the request path.
Be Careful in Dynamic Plugin Systems
Caching is good, but in dynamic environments it also needs an ownership story.
If classes can appear and disappear over time, unbounded caches keyed by class or classloader can become a leak.
That means reflection optimization has to match the lifecycle model of the system, not just the benchmark.
Profiling Still Comes First
This article only makes sense when the reflective cost is measured.
If profiling shows reflection is not meaningfully present in the critical path, broad rewrites are usually a waste.
Tip
Reflection often gets blamed because it is easy to see in code. Optimize it only when it is also easy to see in the profile.
Key Takeaways
- Reflection is fine in many places; repeated reflection in hot paths is not.
- Cache metadata first before reaching for more invasive changes.
- Use
MethodHandleor generated code when a stable reflective hotspot remains. - Always distinguish startup costs from request-time costs before optimizing.
Categories
Tags