How do you troubleshoot excessive memory usage in a Micronaut native image at runtime?

Native image memory issues usually trace back to a handful of causes distinct from typical JVM heap tuning, since native images manage memory somewhat differently, with no dynamic class loading and different GC defaults.

1. Check the GC in use. Native image defaults to the Serial GC unless configured otherwise; for services under real load, switching to the G1 GC at build time often reduces pause-related memory pressure significantly.
2. Profile heap usage with native-image-specific tooling. VisualVM or async-profiler both work against a running native binary, unlike some JVM-only profilers.
3. Look for unexpectedly large included resources or classes. Overly broad reflection or resource configuration can bloat the image and its runtime metadata footprint unnecessarily.
4. Check connection pool and cache sizing. These are ordinary application-level memory users no different from a JVM deployment, and are a common culprit misattributed to "native image weirdness."
5. Compare against a JVM run of the same code under the same load; if memory usage is similar, the issue is application-level, not native-image-specific.

Most "native image uses too much memory" reports turn out to be ordinary application memory issues once isolated this way, rather than something inherent to native compilation itself.