Introduction to PHP recycling cycle

This article brings you an introduction to the PHP recycling cycle. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.

The following procedure only works for array and object types.

Traditionally, the reference counting memory mechanism used in PHP cannot handle circular reference memory leaks. However, PHP 5.3.0 uses the synchronization algorithm in the article » Concurrent Cycle Collection in Reference Counted Systems to deal with this memory leak problem.

A complete description of the algorithm is somewhat beyond the scope of this section, and only the basics will be introduced. First, we need to establish some basic rules. If a reference count is increased, it will continue to be used and of course no longer in the garbage. If the reference count is reduced to zero, the variable container will be cleared (free). That is, a garbage cycle occurs only when the reference count decreases to a non-zero value. Secondly, during a garbage cycle, find out which parts are garbage by checking whether the reference count is reduced by 1 and checking which variable containers have zero references.

To avoid having to check all garbage cycles where the reference count may be reduced, this algorithm puts all possible roots (possible roots are zval variable containers) in the root buffer (root buffer) (marked in purple, called suspected garbage), this can also ensure that each possible garbage root (possible garbage root) appears only once in the buffer. Garbage collection is performed on all different variable containers within the buffer only when the root buffer is full. Look at step A in the image above.

In step B, simulate deleting each purple variable. When simulating deletion, the reference count of ordinary variables that are not purple may be reduced by "1". If the reference count of an ordinary variable becomes 0, simulate deletion of this ordinary variable again. Each variable can only be simulated deleted once, and it will be marked gray after simulated deletion (the original article said to ensure that the same variable container is not decremented by "1" twice, which is wrong).

In step C, the simulation restores each purple variable. Recovery is conditional. When the reference count of the variable is greater than 0, simulated recovery is performed. Similarly, each variable can only be restored once. After restoration, it is marked as black. It is basically the inverse operation of step B. In this way, the remaining pile of unrecoverable blue nodes are the blue nodes that should be deleted. Traverse them in step D and delete them.

The algorithms are all simulated deletion, simulated recovery, and real deletion, all using simple traversal (the most typical deep search traversal). The complexity is positively related to the number of nodes performing simulation operations, not just those suspected garbage variables in purple.

Now that you have a basic understanding of this algorithm, let's go back and see how this is integrated with PHP. By default, PHP's garbage collection mechanism is turned on, and there is a php.ini setting that allows you to modify it: zend.enable_gc.

When the garbage collection mechanism is turned on, the loop search algorithm described above will be executed whenever the root buffer is full. The root cache area has a fixed size and can store 10,000 possible roots. Of course, you can modify this 10,000 value by modifying the constant GC_ROOT_BUFFER_MAX_ENTRIES in the PHP source file Zend/zend_gc.c and then recompiling PHP. When garbage collection is turned off, the loop search algorithm never executes, however, it is possible that the root will always exist in the root buffer regardless of whether garbage collection is activated in the configuration.

When the garbage collection mechanism is turned off, if the root buffer is full of possible roots, more possible roots will obviously not be recorded. Possible roots that are not recorded will not be analyzed and processed by this algorithm. If they are part of a cyclic reference cycle, they will never be cleared and cause a memory leak.

The reason possible roots are recorded even when garbage collection is unavailable is that recording possible roots is faster than checking whether garbage collection is turned on each time a possible root is found. However, the garbage collection and analysis mechanism itself takes a lot of time.

In addition to modifying the configuration zend.enable_gc, you can also turn on and off the garbage collection mechanism by calling the gc_enable() and gc_disable() functions respectively. Calling these functions has the same effect as modifying configuration items to turn on or off the garbage collection mechanism. Ability to force periodic collection even when the root buffer may not be full. You can call the gc_collect_cycles() function for this purpose. This function will return the number of cycles recycled using this algorithm.

The reason you allow turning garbage collection on and off and allowing autonomous initialization is because some parts of your application may be time-sensitive. In this case, you probably don't want to use garbage collection. Of course, turning off garbage collection for certain parts of your application runs the risk of possible memory leaks, since some possible roots may not fit into the limited root buffer. Therefore, just before you call the gc_disable() function to release the memory, it may be wise to call the gc_collect_cycles() function first. Because this will clear all possible roots that have been stored in the root buffer, then when the garbage collection mechanism is turned off, an empty buffer can be left to have more space to store possible roots.

The above is the detailed content of Introduction to PHP recycling cycle. For more information, please follow other related articles on the PHP Chinese website!