Как на самом деле работает PHP 'foreach'?

foreach поддерживает итерацию по трем различным типам значений:

• Массивы
• Обычные объекты
• Traversable объекты

В дальнейшем я попытаюсь точно объяснить, как работает итерация в разных случаях. Безусловно, самым простым случаем являются объекты с возможностью Traversable, так как для этих foreach в основном используется только синтаксический сахар для кода в этих строках:

foreach ($it as $k => $v) { /* ... */ }

/* translates to: */

if ($it instanceof IteratorAggregate) {
    $it = $it->getIterator();
}
for ($it->rewind(); $it->valid(); $it->next()) {
    $v = $it->current();
    $k = $it->key();
    /* ... */
}

Для внутренних классов вызовы фактических методов избегаются с помощью внутреннего API, который по существу просто отражает интерфейс Iterator на уровне C.

Итерация массивов и простых объектов значительно сложнее. Прежде всего, следует отметить, что в PHP "массивы" действительно упорядоченные словари, и они пройдут в соответствии с этим порядком (который соответствует порядку вставки, если вы не использовали что-то вроде sort). Это противоречит итерации естественным порядком ключей (как часто работают списки на других языках) или вообще не имеет определенного порядка (как часто работают словари на других языках).

То же самое относится и к объектам, поскольку свойства объекта можно рассматривать как другие (упорядоченные) словарные имена для преобразования словаря в их значения, а также некоторую обработку видимости. В большинстве случаев свойства объекта фактически не хранятся в этом довольно неэффективном способе. Однако, если вы начинаете выполнять итерацию над объектом, упакованное представление, которое обычно используется, будет преобразовано в настоящий словарь. В этот момент итерация простых объектов очень похожа на итерацию массивов (вот почему я не обсуждаю здесь итерацию простого объекта).

Все идет нормально. Итерация по словарю не может быть слишком сложной, не так ли? Проблемы начинаются, когда вы понимаете, что массив/объект может меняться во время итерации. Это может произойти несколькими способами:

• Если вы перебираете по ссылке с помощью foreach ($arr as &$v) то $arr превращается в ссылку, и вы можете изменить ее во время итерации.
• В PHP 5 одинаково применяется, даже если вы итерации по значению, но массив был ссылкой заранее: $ref =& $arr; foreach ($ref as $v) $ref =& $arr; foreach ($ref as $v)
• Объекты имеют сквозную семантику по-методу, которая для практических целей означает, что они ведут себя как ссылки. Таким образом, объекты всегда могут быть изменены во время итерации.

Проблема с разрешительными изменениями во время итерации - это тот случай, когда элемент, в котором вы сейчас находитесь, удален. Скажем, вы используете указатель, чтобы отслеживать, какой элемент массива вы сейчас находитесь. Если этот элемент теперь освобожден, вы останетесь с висящим указателем (обычно это приводит к segfault).

Существуют различные способы решения этой проблемы. PHP 5 и PHP 7 значительно отличаются в этом отношении, и я опишу оба поведения в следующем. Резюме состоит в том, что подход PHP 5 был довольно глупым и приводил к возникновению всех видов странных краевых проблем, в то время как более высокий уровень взаимодействия с PHP 7 приводил к более предсказуемому и последовательному поведению.

Как последнее предварительное, следует отметить, что PHP использует подсчет ссылок и копирование на запись для управления памятью. Это означает, что если вы "скопируете" значение, вы фактически просто повторно используете старое значение и увеличиваете его счетчик ссылок (refcount). Только после выполнения какой-либо модификации будет выполнена реальная копия (называемая "дублированием"). Смотрите, что вы лгали для более подробного введения в эту тему.

PHP 5

Внутренний указатель массива и HashPointer

Массивы в PHP 5 имеют один выделенный "указатель внутренних массивов" (IAP), который правильно поддерживает модификации: всякий раз, когда элемент удаляется, будет проверяться, указывает ли IAP этот элемент. Если это так, то вместо этого он переходит к следующему элементу.

В то время как foreach использует IAP, существует дополнительное усложнение: существует только один IAP, но один массив может быть частью нескольких циклов foreach:

// Using by-ref iteration here to make sure that it really
// the same array in both loops and not a copy
foreach ($arr as &$v1) {
    foreach ($arr as &$v) {
        // ...
    }
}

Для поддержки двух одновременных циклов с одним внутренним указателем массива foreach выполняет следующие сценарии: до того, как тело цикла будет выполнено, foreach вернет указатель на текущий элемент и его хеш в HashPointer -foreach. После того, как тело цикла будет запущено, IAP будет возвращен к этому элементу, если он все еще существует. Однако, если элемент был удален, мы будем использовать только то, что сейчас находится в IAP. Эта схема в основном-kinda-sortof работает, но есть много странного поведения, из-за которого вы можете выйти, некоторые из которых я продемонстрирую ниже.

Дублирование массива

IAP - видимая функция массива (отображается через current семейство функций), так как такие изменения в IAP считаются модификациями в семантике copy-on-write. Это, к сожалению, означает, что foreach во многих случаях вынуждает дублировать массив, который он итерирует. Точные условия:

1. Массив не является ссылкой (is_ref = 0). Если это ссылка, то изменения в ней должны распространяться, поэтому ее не следует дублировать.
2. Массив имеет refcount> 1. Если refcount равен 1, массив не используется, и мы можем свободно его изменять.

Если массив не дублируется (is_ref = 0, refcount = 1), то только его refcount будет увеличиваться (*). Кроме того, если используется foreach по ссылке, то (потенциально дублированный) массив будет превращен в ссылку.

Рассмотрим этот код как пример, где происходит дублирование:

function iterate($arr) {
    foreach ($arr as $v) {}
}

$outerArr = [0, 1, 2, 3, 4];
iterate($outerArr);

Здесь $arr будет дублироваться, чтобы предотвратить изменения IAP на $arr от утечки до $outerArr. В терминах вышеприведенных условий массив не является ссылкой (is_ref = 0) и используется в двух местах (refcount = 2). Это требование является неудачным и является артефактом субоптимальной реализации (здесь нет никакой модификации во время итерации, поэтому нам действительно не нужно использовать IAP в первую очередь).

(*) Инкремент пересчета здесь звучит безобидно, но нарушает семантику copy-on-write (COW): это означает, что мы собираемся изменить IAP массива refcount = 2, в то время как COW диктует, что изменения могут быть выполнены только при пересчете = 1. Это нарушение приводит к изменению поведения пользователя (в то время как COW обычно прозрачен), поскольку изменение IAP в итерированном массиве будет наблюдаемым - но только до первой модификации, отличной от IAP в массиве. Вместо этого тремя "действительными" параметрами были бы: а) чтобы всегда дублировать, b) чтобы не увеличивать коэффициент пересчета и, таким образом, позволяя произвольно модифицировать итерированный массив в цикле или в) вообще не использовать IAP ( решение для PHP 7).

Порядок продвижения позиции

Существует одна последняя деталь реализации, которую вы должны знать, чтобы правильно понять примеры кода ниже. "Обычный" способ циклы через некоторую структуру данных будет выглядеть примерно так в псевдокоде:

reset(arr);
while (get_current_data(arr, &data) == SUCCESS) {
    code();
    move_forward(arr);
}

Однако, foreach, что, будучи довольно специальной снежинкой, он предпочитает делать что-то по-другому:

reset(arr);
while (get_current_data(arr, &data) == SUCCESS) {
    move_forward(arr);
    code();
}

А именно, указатель массива уже перемещается вперед, прежде чем тело цикла будет запущено. Это означает, что, пока тело цикла работает над элементом $i, IAP уже находится в элементе $i+1. Вот почему примеры кода, отображающие модификацию во время итерации, всегда будут отменять следующий элемент, а не текущий.

Примеры: ваши тестовые примеры

Три аспекта, описанные выше, должны дать вам в основном полное представление об идиосинкратиях реализации foreach, и мы можем перейти к обсуждению некоторых примеров.

Поведение ваших тестовых случаев просто объяснить на данный момент:

• В тестовых случаях 1 и 2 $array начинаются с refcount = 1, поэтому он не будет дублироваться foreach: только пересчет увеличивается. Когда тело цикла впоследствии изменяет массив (который имеет refcount = 2 в этой точке), дублирование произойдет в этой точке. Foreach продолжит работу над немодифицированной копией $array.

• В тестовом примере 3 снова массив не дублируется, поэтому foreach будет изменять IAP переменной $array. В конце итерации МАП является NULL (то есть итерация сделано), который each указывает на возвращение false.

• В тестовых примерах 4 и 5 как each и reset являются по ссылке функции. $array имеет refcount=2 когда он передается им, поэтому его нужно дублировать. Поскольку такой foreach снова будет работать над отдельным массивом.

Примеры: Влияние current в foreach

Хорошим способом показать поведение различных дубликатов является наблюдение за поведением функции current() внутри цикла foreach. Рассмотрим этот пример:

foreach ($array as $val) {
    var_dump(current($array));
}
/* Output: 2 2 2 2 2 */

Здесь вы должны знать, что current() является функцией by-ref (на самом деле: prefer-ref), хотя он не модифицирует массив. Это должно быть для того, чтобы играть хорошо со всеми другими функциями, такими как next которые все по-ref. Прохождение байтов означает, что массив должен быть разделен, и поэтому $array и $array foreach будут разными. Причина, по которой вы получаете 2 вместо 1, также упоминается выше: foreach продвигает указатель массива перед запуском кода пользователя, а не после. Поэтому, хотя код находится в первом элементе, foreach уже продвинул указатель ко второму.

Теперь попробуем небольшую модификацию:

$ref = &$array;
foreach ($array as $val) {
    var_dump(current($array));
}
/* Output: 2 3 4 5 false */

Здесь мы имеем случай is_ref = 1, поэтому массив не копируется (как и выше). Но теперь, когда это ссылка, массив больше не должен дублироваться при переходе к функции by-ref current(). Таким образом, current() и foreach работают с одним и тем же массивом. Тем не менее, вы по-прежнему видите поведение по отдельности, из-за того, что foreach продвигает указатель.

При выполнении повторной итерации вы получаете такое же поведение:

foreach ($array as &$val) {
    var_dump(current($array));
}
/* Output: 2 3 4 5 false */

Здесь важная часть заключается в том, что foreach будет делать $array a is_ref = 1, когда он повторяется по ссылке, поэтому в основном вы имеете ту же ситуацию, что и выше.

Еще одна небольшая вариация, на этот раз мы назначим массив другой переменной:

$foo = $array;
foreach ($array as $val) {
    var_dump(current($array));
}
/* Output: 1 1 1 1 1 */

Здесь refcount $array равен 2, когда цикл запущен, так что на этот раз нам действительно нужно сделать дублирование заранее. Таким образом, $array и массив, используемые foreach, будут полностью отделены от начала. Вот почему вы получаете позицию IAP везде, где она была до цикла (в этом случае она была на первой позиции).

Примеры: изменение во время итерации

Попытка учитывать изменения во время итерации - это то, где возникли все наши проблемы с foreach, поэтому он служит для рассмотрения некоторых примеров для этого случая.

Рассмотрим эти вложенные циклы над одним и тем же массивом (где by-ref итерация используется, чтобы убедиться, что она действительно одна и та же):

foreach ($array as &$v1) {
    foreach ($array as &$v2) {
        if ($v1 == 1 && $v2 == 1) {
            unset($array[1]);
        }
        echo "($v1, $v2)\n";
    }
}

// Output: (1, 1) (1, 3) (1, 4) (1, 5)

Ожидаемая часть здесь состоит в том, что (1, 2) отсутствует на выходе, потому что элемент 1 удален. Вероятно, неожиданным является то, что внешний цикл останавливается после первого элемента. Почему это?

Причиной этого является хакеры вложенных циклов, описанные выше: до того, как тело цикла будет HashPointer, текущая позиция IAP и хэш будут скопированы в HashPointer. После тела цикла он будет восстановлен, но только если элемент все еще существует, в противном случае вместо этого используется текущая позиция IAP (что бы это ни было). В приведенном выше примере это точно так: текущий элемент внешнего цикла был удален, поэтому он будет использовать IAP, который уже был отмечен как завершенный внутренним циклом!

Другим следствием HashPointer резервного копирования + восстановления HashPointer является то, что изменения в IAP, хотя reset() и т.д. Обычно не влияют на foreach. Например, следующий код выполняется так, как если бы reset() не присутствовал вообще:

$array = [1, 2, 3, 4, 5];
foreach ($array as &$value) {
    var_dump($value);
    reset($array);
}
// output: 1, 2, 3, 4, 5

Причина в том, что, в то время как reset() временно изменяет IAP, он будет возвращен к текущему элементу foreach после тела цикла. Чтобы принудительно reset() чтобы повлиять на цикл, вам необходимо дополнительно удалить текущий элемент, чтобы механизм резервного копирования/восстановления завершился с ошибкой:

$array = [1, 2, 3, 4, 5];
$ref =& $array;
foreach ($array as $value) {
    var_dump($value);
    unset($array[1]);
    reset($array);
}
// output: 1, 1, 3, 4, 5

Но эти примеры по-прежнему являются нормальными. Настоящее удовольствие начинается, если вы помните, что восстановление HashPointer использует указатель на элемент и его хэш, чтобы определить, существует ли он еще. Но: у хэшей есть коллизии, а указатели можно использовать повторно! Это означает, что при тщательном выборе ключей массива мы можем заставить foreach полагать, что элемент, который был удален, все еще существует, поэтому он будет прыгать прямо к нему. Пример:

$array = ['EzEz' => 1, 'EzFY' => 2, 'FYEz' => 3];
$ref =& $array;
foreach ($array as $value) {
    unset($array['EzFY']);
    $array['FYFY'] = 4;
    reset($array);
    var_dump($value);
}
// output: 1, 4

Здесь мы обычно должны ожидать выхода 1, 1, 3, 4 соответствии с предыдущими правилами. Что происходит, так это то, что 'FYFY' имеет тот же хеш, что и удаленный элемент 'EzFY', и распределитель 'EzFY' использует одно и то же место памяти для хранения элемента. Таким образом, foreach попадает прямо к вновь вставленному элементу, тем самым сокращая петлю.

Подстановка повторяющегося объекта во время цикла

Последний последний случай, который я хотел бы упомянуть, заключается в том, что PHP позволяет вам заменить итерированный объект во время цикла. Таким образом, вы можете начать итерацию на одном массиве, а затем заменить его другим массивом на полпути. Или начните выполнять итерацию по массиву, а затем замените его на объект:

$arr = [1, 2, 3, 4, 5];
$obj = (object) [6, 7, 8, 9, 10];

$ref =& $arr;
foreach ($ref as $val) {
    echo "$val\n";
    if ($val == 3) {
        $ref = $obj;
    }
}
/* Output: 1 2 3 6 7 8 9 10 */

Как вы можете видеть, в этом случае PHP начнет повторять итерацию другого объекта с самого начала, как только произойдет замена.

PHP 7

Итераторы Hashtable

Если вы все еще помните, основная проблема с итерацией массива заключалась в том, как обрабатывать удаление элементов в середине итерации. PHP 5 использовал для этой цели один внутренний указатель массива (IAP), который был несколько субоптимальным, поскольку один указатель на массив должен был растягиваться для поддержки нескольких одновременных циклов foreach и взаимодействия с reset() и т.д. Кроме этого.

PHP 7 использует другой подход, а именно поддерживает произвольное количество внешних, безопасных итераторов хэш-таблицы. Эти итераторы должны быть зарегистрированы в массиве, откуда они имеют одинаковую семантику, как и IAP: если элемент массива удален, все итераторы хеш-таблицы, указывающие на этот элемент, будут переходить к следующему элементу.

Это означает, что Еогеасп больше не будет использовать IAP вообще. Цикл foreach абсолютно не влияет на результаты current() и т.д., И его собственное поведение никогда не будет влиять на функции типа reset() и т.д.

Дублирование массива

Еще одно важное изменение между PHP 5 и PHP 7 связано с дублированием массива. Теперь, когда IAP больше не используется, итерация массива по-величине будет делать только приращение refcount (вместо дублирования массива) во всех случаях. Если массив изменен во время цикла foreach, в этот момент произойдет дублирование (в соответствии с копией на запись), и foreach продолжит работу над старым массивом.

В большинстве случаев это изменение является прозрачным и не имеет другого эффекта, чем лучшая производительность. Однако есть один случай, когда это приводит к разному поведению, а именно к случаю, когда массив был ссылкой заранее:

$array = [1, 2, 3, 4, 5];
$ref = &$array;
foreach ($array as $val) {
    var_dump($val);
    $array[2] = 0;
}
/* Old output: 1, 2, 0, 4, 5 */
/* New output: 1, 2, 3, 4, 5 */

Раньше итерация ссылочных массивов по отдельности была специальными случаями. В этом случае дублирование не произошло, поэтому все изменения массива во время итерации будут отражены в цикле. В PHP 7 этот частный случай ушел: итерация байтов по значению всегда будет продолжать работать с исходными элементами, не обращая внимания на любые изменения во время цикла.

Это, конечно же, не относится к итерации ссылок. Если вы перечислите по ссылке, все изменения будут отражены в цикле. Интересно, что то же самое верно и для итерации с равными значениями простых объектов:

$obj = new stdClass;
$obj->foo = 1;
$obj->bar = 2;
foreach ($obj as $val) {
    var_dump($val);
    $obj->bar = 42;
}
/* Old and new output: 1, 42 */

Это отражает семантику объектов с помощью дескриптора (т.е. они ведут себя как ссылочный, даже в контекстах по значению).

Примеры

Давайте рассмотрим несколько примеров, начиная с ваших тестовых случаев:

• Контрольные случаи 1 и 2 сохраняют один и тот же результат: итерация массива по-прежнему всегда работает с исходными элементами. (В этом случае даже пересчет и поведение дублирования точно совпадают между PHP 5 и PHP 7).

• Тестовый случай 3 изменения: Foreach больше не использует IAP, поэтому each() не зависит от цикла. Он будет иметь тот же результат до и после.

• Тесты 4 и 5 остаются неизменными: each() и reset() будут дублировать массив перед изменением IAP, в то время как foreach все еще использует исходный массив. (Не то, чтобы изменение IAP имело значение, даже если массив был разделен.)

Второй набор примеров был связан с поведением current() в разных конфигурациях reference/refcounting. Это уже не имеет смысла, так как current() полностью не зависит от цикла, поэтому его возвращаемое значение всегда остается неизменным.

Однако при рассмотрении изменений во время итерации мы получаем некоторые интересные изменения. Надеюсь, вы найдете новое поведение более разумным. Первый пример:

$array = [1, 2, 3, 4, 5];
foreach ($array as &$v1) {
    foreach ($array as &$v2) {
        if ($v1 == 1 && $v2 == 1) {
            unset($array[1]);
        }
        echo "($v1, $v2)\n";
    }
}

// Old output: (1, 1) (1, 3) (1, 4) (1, 5)
// New output: (1, 1) (1, 3) (1, 4) (1, 5)
//             (3, 1) (3, 3) (3, 4) (3, 5)
//             (4, 1) (4, 3) (4, 4) (4, 5)
//             (5, 1) (5, 3) (5, 4) (5, 5) 

Как вы можете видеть, внешний цикл больше не прерывается после первой итерации. Причина в том, что обе циклы теперь имеют полностью отдельные итераторы хэш-таблицы, и больше нет перекрестного заражения обеих петель через общий IAP.

Еще один странный краевой случай, который исправлен сейчас, - это нечетный эффект, который вы получаете, когда вы удаляете и добавляете элементы, которые имеют одинаковый хеш:

$array = ['EzEz' => 1, 'EzFY' => 2, 'FYEz' => 3];
foreach ($array as &$value) {
    unset($array['EzFY']);
    $array['FYFY'] = 4;
    var_dump($value);
}
// Old output: 1, 4
// New output: 1, 3, 4

Ранее механизм восстановления HashPointer переместился прямо к новому элементу, потому что он "выглядел" так же, как и элемент remove (из-за встречного хэша и указателя). Поскольку мы больше не полагаемся на хэш элементов для чего-либо, это уже не проблема.