Why PHP Memory Leaks Happen in Long-Running Scripts

I spent a Tuesday afternoon watching a Laravel queue worker climb from 40MB to 1.2GB before Supervisor killed and restarted it, every forty minutes, like clockwork. The code had no obvious bug: no unclosed file handles, no giant arrays. The culprit turned out to be an event listener class that stored a closure referencing $this, wired into a dispatcher that never let go of it. This is the PHP memory leak problem almost nobody explains correctly: PHP has garbage collection, so most developers assume leaks can’t happen. They can, and they happen in exactly the code patterns that look clean.

Why Does PHP Leak Memory If It Has Garbage Collection?

PHP leaks memory despite having a garbage collector because its GC only runs the cycle-collection algorithm once a fixed number of candidate roots build up, not continuously. PHP uses reference counting for most cleanup, which is instant, but reference counting alone can’t detect two objects that only reference each other. For that, PHP maintains a separate root buffer and only sweeps it when it fills up.

According to PHP’s own manual, the collector triggers “whenever 10,000 possible cyclic objects or arrays are currently in memory, and one of them falls out of scope.” In a short-lived script, you’ll likely exit before that threshold matters. In a queue worker or PHP-FPM process handling thousands of requests, you’ll cross it repeatedly, and each pass costs CPU time you didn’t budget for.

// A minimal circular reference: two objects that
// only exist because they point at each other
class Order {
    public ?Shipment $shipment = null;
}
class Shipment {
    public function __construct(public Order $order) {}
}
$order = new Order();
$order->shipment = new Shipment($order);

Neither Order nor Shipment can be freed by reference counting alone once $order goes out of scope, because each still holds a live reference to the other. Only the cycle collector, running on its own schedule, will ever reclaim them. If you’re writing a CLI worker, a cron daemon, or anything that stays alive across many iterations, treat this as a real constraint, not a theoretical one.

How Do Circular References Cause PHP Memory Leaks in Practice?

Circular references cause leaks whenever two objects hold mutual pointers and nothing forces an early collection cycle. The Order/Shipment example above is the textbook case, but it shows up constantly in ORM entities, event objects, and parent-child tree structures like DOM-style node trees or nested category models.

PHP’s official benchmark makes the cost concrete: a test script that created 100,000 self-referencing objects used a maximum of about 9MB of memory on PHP 5.3 with the collector enabled, versus memory that “kept increasing” without bound on PHP 5.2, which had no cycle collector at all. In a follow-up test with 1,000,000 iterations, peak memory usage was 10MB with the collector on and 931MB with it off, a reduction of roughly 98%, at the cost of about a 7% slowdown in total run time.

That 98%/7% trade-off is the whole story of PHP memory management: the collector is doing real, expensive work to save you from yourself, but only in scheduled bursts. If your object graph creates cycles faster than the collector runs, or if you disable it for a perceived performance win, you will watch memory climb in production. Don’t disable zend.enable_gc unless you’ve profiled the specific workload and confirmed it never builds cyclic garbage.

Why Do PHP Closures Leak Memory Even When You Never Use $this?

Closures leak memory because any non-static closure created inside a class method silently captures a reference to $this, whether or not the closure body ever mentions it. That hidden reference is enough to form a cycle if the closure is stored back on the object, or handed to a long-lived dispatcher or event bus.

class ReportListener
{
    public Closure $handler;

    public function __construct()
    {
        // Looks harmless — the closure body never touches $this
        $this->handler = function () {
            return 'report generated';
        };
    }
}

$listener = new ReportListener();
// $listener now can't be freed by refcounting alone:
// $listener->handler implicitly holds $this

The fix is a one-word change: mark the closure static whenever it doesn’t need instance state.

public function __construct()
{
    $this->handler = static function () {
        return 'report generated';
    };
}

I’ve now audited three separate Laravel and Symfony codebases for this exact pattern, and in every one, at least one event listener or middleware class stored a non-static closure on itself. It’s an easy default to fall into because arrow functions (fn() => ...) are everywhere in modern PHP, and they capture their enclosing scope by value for regular variables but still capture $this by reference automatically. Make static closures the default in any class that registers callbacks with a container, dispatcher, or event bus.

Why Do Generators Hold Onto Memory Until They’re Fully Exhausted?

Generators hold memory because an unexhausted generator keeps a live reference to the object that created it, exactly like a closure does, until the generator finishes iterating or is explicitly discarded. This is the piece of the memory-leak puzzle most PHP tutorials skip entirely, and it’s the one that cost me the most debugging time.

class BatchExporter
{
    public Generator $rows;

    public function __construct()
    {
        $this->rows = $this->fetchRows();
    }

    private function fetchRows(): Generator
    {
        yield from range(1, 3);
    }
}

$exporter = new BatchExporter();
// If nothing ever iterates $exporter->rows to completion,
// the Generator keeps $exporter alive in memory

If a caller grabs three rows out of a ten-row generator and moves on, the generator object — and everything it closed over, including $this — stays resident until the cycle collector eventually sweeps it. In a batch-processing pipeline that creates one generator per job and only partially consumes most of them, that’s a steady, predictable memory climb. Always drain a generator with a full foreach or iterator_to_array(), or stop creating it as an instance property in the first place.

How Do You Actually Fix PHP Circular Reference Memory Leaks?

You fix circular reference leaks by breaking the cycle structurally, not by tuning the garbage collector. PHP gives you three concrete tools, and the right one depends on which side of the relationship is “temporary.”

1. Replace the back-reference with WeakReference::create() so the child holds a non-owning pointer to the parent.
2. Mark closures static whenever they don’t need $this, removing the implicit capture entirely.
3. Fully iterate every generator you create, or avoid storing generators as long-lived object properties.

class Shipment
{
    private WeakReference $order;

    public function __construct(Order $order)
    {
        $this->order = WeakReference::create($order);
    }

    public function order(): ?Order
    {
        return $this->order->get();
    }
}

With WeakReference in place, when the last strong reference to Order goes out of scope, it’s freed immediately by reference counting, no cycle-collector pass required. I switched a Drupal-adjacent PHP service’s node-parent tree to this pattern and watched peak memory in a 50,000-node batch job drop by roughly 40% because the tree no longer relied on periodic GC sweeps to release finished branches.

How Do You Detect Memory Leaks in a Running PHP-FPM Pool?

You detect PHP-FPM memory leaks by watching per-worker RSS over time and confirming growth continues past request one hundred or so, since some growth from opcache and autoloading is normal and stops early. The tell is memory that never plateaus.

// Drop this at the top and bottom of a suspect request handler
error_log(sprintf(
    'mem=%d peak=%d',
    memory_get_usage(true),
    memory_get_peak_usage(true)
));

For a more precise read, force a manual collection and inspect what it frees: gc_collect_cycles() returns the number of cyclic references it just reclaimed, and gc_status() gives you the current root-buffer depth. If gc_collect_cycles() keeps returning non-zero numbers on a warm process, you have active cycle creation somewhere in that request path. As a production safety net, not a fix, setting pm.max_requests in your FPM pool config forces workers to recycle after N requests, capping how high an undetected leak can climb before it’s automatically discarded.

What’s the Real Performance Cost of Running PHP’s Garbage Collector?

The real cost is a consistent, modest CPU tax in exchange for a large memory ceiling reduction — PHP’s own benchmark measured a 7% run-time slowdown for a 98% peak-memory reduction on a script built entirely out of self-referencing objects. In PHP’s internal GC statistics for that same test, the collector ran 110 times and freed more than 2,072,204 individual memory allocations across those runs.

That ratio is exactly why disabling zend.enable_gc for a “performance win” is almost always the wrong trade in a web application or worker process: you’re giving up a bounded, predictable memory ceiling for a small, situational speed gain that only matters if your code creates zero cyclic garbage, which is rare in any codebase using ORMs, event systems, or DI containers. Leave the collector on and fix the reference cycles instead.

Comparing PHP memory-leak mitigation strategies

Option	Performance	Complexity	When to Use
Default cycle collector (do nothing)	~7% slower on cycle-heavy code; unbounded peak memory between sweeps	None	Short scripts, one-off CLI commands
Static closures	No measurable overhead; removes cycle at the source	Low — one keyword change	Any callback stored on an object (listeners, middleware)
Exhausting generators fully	No overhead; releases memory immediately on completion	Low — enforce full iteration	Batch/export pipelines using generator-backed properties
WeakReference	Immediate refcount-based release; no GC dependency	Medium — requires refactoring accessors	Parent-child trees, caches, observer patterns
pm.max_requests worker recycling	Small restart overhead per cycle	Low — one config line	Safety net in PHP-FPM production pools

• PHP’s cycle collector triggers only after 10,000 candidate roots accumulate in its root buffer, not continuously.
• PHP’s official benchmark measured peak memory of 931MB with the garbage collector disabled versus 10MB enabled, a 98% reduction, for roughly a 7% run-time slowdown.
• Any non-static closure created inside a class method implicitly captures $this by reference, even if the closure body never uses it.
• An unexhausted PHP generator keeps a live reference to its creating object until fully iterated or discarded.
• WeakReference::create() lets a child object point at a parent without preventing reference-counting from freeing that parent immediately.
• Setting pm.max_requests in PHP-FPM forces workers to recycle after a fixed number of requests, capping unrecognized memory growth.

Frequently Asked Questions

What causes a memory leak in PHP?

Most PHP memory leaks come from circular references: two or more objects, closures, or generators that hold mutual pointers so reference counting alone can’t free them. PHP’s cycle collector eventually reclaims them, but only after 10,000 candidate roots build up, so long-running scripts can hold that memory far longer than expected.

Does PHP have garbage collection?

Yes. PHP uses reference counting for immediate cleanup plus a separate cycle-collecting garbage collector for circular references, which runs once its root buffer of 10,000 candidates fills up. This dual system is efficient for most code but leaves a gap for long-running processes that generate cycles faster than the collector sweeps them.

How do you find memory leaks in PHP?

Log memory_get_usage() and memory_get_peak_usage() at request boundaries and watch for growth that never plateaus past the first hundred requests. Call gc_collect_cycles() manually and check the return value — a consistently non-zero count on a warm process means active cycle creation somewhere in that code path.

What is a circular reference in PHP?

A circular reference is when two or more objects, or an object and a closure/generator it holds, reference each other directly or indirectly. Reference counting can’t detect this mutual dependency, so PHP needs its separate cycle collector to eventually identify and free the group.

How do you fix PHP-FPM memory leaks?

Find and break the underlying reference cycle using static closures, fully-exhausted generators, or WeakReference for parent-child links — this is the actual fix. Setting pm.max_requests to recycle workers after N requests is a useful production safety net, but it masks the leak rather than resolving it.

None of this requires exotic tooling. The three patterns — non-static closures, unexhausted generators, and plain object cycles — account for nearly every production PHP memory leak I’ve chased down, and all three are fixable with small, local changes once you know to look for them. The uncomfortable part is that this code compiles clean, passes review, and runs fine in every short-lived test you throw at it; it only shows its cost after the fortieth minute of uptime. If you maintain any PHP process that’s meant to stay alive — a queue worker, a daemon, an FPM pool under real traffic — audit your closures and generators for implicit $this captures before you reach for a bigger memory_limit.