How would you troubleshoot a suspected memory leak using AppDynamics?

AppDynamics won't point at the exact leaking object automatically, but it gives you the signal that narrows where to look and the tooling to confirm it, rather than guessing blind.

1. Spot the trend: in the Metric Browser, watch heap usage (or a specific memory pool) over hours or days — a leak shows a saw-tooth pattern where garbage collection reclaims less each cycle, so the floor keeps rising.
2. Correlate with GC metrics: rising GC frequency and duration alongside climbing heap usage suggests the JVM working harder to reclaim shrinking free space.
3. Check for a matching Business Transaction pattern: see whether response times or error rates degrade on the same timeline, which tells you if the leak is customer-visible yet or still headroom.
4. Trigger diagnostic actions: attach a policy to capture a heap dump (via a custom diagnostic action or Machine Agent extension) at a threshold, so you have an artifact to analyze offline with a tool like Eclipse MAT.

The key discipline is correlating the memory trend with deployment timestamps: if the saw-tooth pattern started right after a specific release, that release is the first place to look for a newly introduced leak, such as an unclosed resource or a growing cache with no eviction policy.