How do you analyze a GC log to identify a memory leak?

Start by enabling detailed unified logging if it isn't already active:

-Xlog:gc*:file=gc.log:time,uptime,level,tags

Load the resulting log into a visualization tool such as GCEasy or GCViewer and focus on old-generation occupancy immediately after each full or major collection - that's the closest approximation to the application's true live-data floor at that point in time. In a healthy application this floor stays roughly flat over hours or days; in a leaking one, it climbs steadily upward collection after collection, even though each individual collection is still doing real work and freeing some memory.

Once the log confirms a rising floor, correlate the timing against deployment or traffic events to narrow down what's driving it, then move to a heap dump for the specifics: jmap -dump:live,format=b,file=heap.hprof <pid> taken at two points separated by enough time for the leak to show clearly, then compared object-by-object in Eclipse MAT's dominator tree or histogram diff view to identify exactly which objects (and which retaining references) are accumulating.