В основе механизма лежит простая идея. Чтобы понять эту идею, достаточно знать типы ссылок. Да те самые типы, которые в большинстве случаев только на собесе и упоминаются. Есть 4 типа ссылок в Java, нас сейчас интересует только 2: сильные (Strong Reference) и слабые (Weak Reference).

С сильными ссылками все просто, пока эта ссылка существует где-то, GC точно не удалит этот объект, который к этой ссылке привязан. Слабые ссылки в таком кейсе не гарантируют сохранение объекта. Другими словами вы создали объект, потом положили его в слабую ссылку, теперь у вас только слабая ссылка. Когда вам понадобится это объект, в ссылке может оказаться просто null. Если GC решит что памяти мало он просто удалит объекты привязанные к слабым ссылкам.

Дальше еще один факт. Если у нас есть одновременно и слабая ссылка и сильная на объект, то GC не будет удалять этот объект при нехватке памяти, а также не разорвет связь между слабой ссылкой и объектом.

Возвращаясь к работе LeakCanary. Разберем просто как отлеживаются утечки в Activity. Во фрагментах, View, сервисах и т.д работает тот же принцип. Сначала библиотека вешает на context приложения специальный листенер который позволяет отслеживать момент, когда любая Activity умирает.

Перехватив момент когда Activity умирает, LeakCanary оборачивает эту Activity в слабую ссылку и сохраняет у себя. Затем сразу запускает GC, точнее сказать рекомендует JVM запустить GC.

После какого-то времени, библиотека смотрит обнулилась ли ссылка. Если обнулилась значит все ок, никакой утечки не было. Если ссылка по-прежнему не null, значит где-то еще есть сильная ссылка, что означает утечку.