Asynchrones Arbeiten galt in PHP lange als Fremdwort, doch seit PHP 8.1 gibt es dafür einen eingebauten Baustein. Eine Fiber ist eine Funktion, die sich mitten im Ablauf anhalten und später genau dort fortsetzen lässt. Dieses Tutorial erklärt den Lebenszyklus aus start, suspend und resume, grenzt Fibers von Generatoren ab und zeigt, warum Frameworks wie ReactPHP und Amp darauf aufbauen.
Was ist eine PHP Fiber?
Mit PHP Fiber hat die Sprache seit PHP 8.1 einen Mechanismus für Cooperative Concurrency. Eine Fiber ist eine pausierbare Funktion: Sie läuft, kann sich an einer beliebigen Stelle selbst anhalten und später genau dort fortgesetzt werden. Dazwischen darf der Hauptcode oder eine andere Fiber arbeiten. Diese Mechanik klingt ähnlich wie bei Generatoren mit yield, geht aber deutlich weiter, weil eine Fiber auch aus tief verschachtelten Funktionsaufrufen heraus suspendieren kann.
Bevor start, suspend und resume an konkreten Beispielen folgen, lohnt sich eine wichtige Erwartungs-Einordnung zur tatsächlichen Parallelität.
Wichtig vorab: PHP Fibers bringen keine echte Parallelität auf mehreren CPU-Kernen. Es bleibt ein Single-Thread-Modell, in dem Aufgaben sich freiwillig die Rechenzeit teilen. Der praktische Nutzen entsteht vor allem dort, wo viel auf I/O gewartet wird, etwa bei mehreren parallelen HTTP-Calls. Genau deshalb sind Fibers das Fundament moderner Async-Frameworks wie ReactPHP und Amp, die auf dieser Basis vollständige Event-Loops aufbauen.
PHP Fiber-Lifecycle: start, suspend, resume
Eine PHP Fiber durchläuft drei zentrale Methoden. Fiber::start() startet die Fiber, Fiber::suspend() hält sie freiwillig an und gibt die Kontrolle zurück, $fiber->resume() setzt sie wieder fort. Ein minimales Beispiel zeigt das Zusammenspiel.
<?php
$fiber = new Fiber(function () {
echo "Fiber gestartet\n";
Fiber::suspend();
echo "Fiber wieder aufgenommen\n";
});
$fiber->start();
echo "Hauptcode laeuft\n";
$fiber->resume();
/* Ausgabe:
Fiber gestartet
Hauptcode laeuft
Fiber wieder aufgenommen */
Beim start() läuft der Closure-Code bis zum ersten Fiber::suspend() und gibt dann die Kontrolle an den Hauptcode zurück. Erst der nachfolgende resume()-Aufruf bringt die Fiber wieder zum Leben. Die Reihenfolge in der Ausgabe macht das Konzept anschaulich: zwei Code-Pfade wechseln sich ab, ohne dass es echte Threads gibt.
Werte zwischen PHP Fiber und Hauptcode austauschen
Der Datenaustausch zwischen PHP Fiber und Hauptcode funktioniert in beide Richtungen. Fiber::suspend() kann einen Wert zurückgeben, der beim aufrufenden start() oder resume() ankommt. Umgekehrt nimmt resume() einen Parameter, der vom Fiber::suspend() als Rückgabewert gelesen wird.
<?php
$fiber = new Fiber(function () {
$vom_haupt = Fiber::suspend('Frage vom Fiber');
return "Fiber bekam: $vom_haupt";
});
$frage = $fiber->start();
echo $frage . "\n";
/* Frage vom Fiber */
$fiber->resume('Antwort vom Hauptcode');
echo $fiber->getReturn() . "\n";
/* Fiber bekam: Antwort vom Hauptcode */
Mit dieser Mechanik lässt sich ein einfaches Frage-Antwort-Spiel zwischen Fiber und Hauptcode bauen. In Frameworks wird daraus typischerweise eine Schleife: Die Fiber suspendiert mit einem "Bitte warte auf I/O X", der Event-Loop löst die I/O-Operation auf und reicht das Ergebnis über resume() zurück. Damit liest sich asynchroner Code linear, ohne Callback-Verschachtelung.
PHP Fiber vs Generatoren: der wichtige Unterschied
Wer schon mit yield und Generatoren gearbeitet hat, sieht sofort die Ähnlichkeit zur PHP Fiber. Beide Konstrukte können pausieren und Werte austauschen. Der entscheidende Unterschied liegt in der Reichweite: Ein Generator kann nur an seiner eigenen yield-Stelle pausieren. Eine Fiber kann hingegen aus jedem beliebigen Funktionsaufruf heraus suspenden, auch tief in einer Aufrufkette.
<?php
function generatorVariant(): Generator
{
yield 'A';
yield 'B';
yield 'C';
}
$gen = generatorVariant();
foreach ($gen as $wert) {
echo $wert . PHP_EOL;
}
$fiber = new Fiber(function () {
Fiber::suspend('A');
Fiber::suspend('B');
Fiber::suspend('C');
});
echo $fiber->start() . PHP_EOL;
echo $fiber->resume() . PHP_EOL;
echo $fiber->resume() . PHP_EOL;
Praktisch heißt das: Ein Generator zwingt die Anwendung dazu, die Pause-Punkte direkt in der Generator-Funktion zu kennzeichnen. Eine Fiber ist viel flexibler, weil ein Aufrufer beliebige Funktionen aufrufen darf, die irgendwo unten Fiber::suspend() aufrufen, ohne dass die Zwischenebenen davon wissen müssen. Genau diese Flexibilität ist der Grund, warum Frameworks wie ReactPHP oder Amp seit PHP 8.1 einen klareren Programmierstil bieten als noch mit Generator-basierten Coroutinen.
Mehrere PHP Fiber-Objekte nebeneinander betreiben
Sobald mehr als eine Aufgabe parallel zu erledigen ist, wird ein Mini-Scheduler für mehrere PHP Fiber-Instanzen interessant. Der Hauptcode iteriert über alle Fibers, ruft resume() auf und kümmert sich um Aufgaben, die bereits beendet sind.
<?php
$jobs = [];
for ($i = 1; $i <= 3; $i++) {
$jobs[$i] = new Fiber(function () use ($i) {
for ($r = 1; $r <= 3; $r++) {
Fiber::suspend("Job $i Runde $r");
}
return "Job $i fertig";
});
}
foreach ($jobs as $job) {
echo $job->start() . "\n";
}
while (count($jobs) > 0) {
foreach ($jobs as $key => $job) {
if ($job->isTerminated()) {
echo $job->getReturn() . "\n";
unset($jobs[$key]);
continue;
}
echo $job->resume() . "\n";
}
}
Diese Round-Robin-Schleife arbeitet alle Jobs ab, bis sie alle terminiert sind. Sie zeigt das Grundprinzip jedes Event-Loops: aktiv prüfen, ob eine Aufgabe noch Arbeit hat, sonst die nächste an die Reihe lassen. Echte Frameworks erweitern dieses Pattern um ereignisgesteuerte Wartepunkte, sodass Fibers nicht alle paar Millisekunden, sondern erst dann wieder geweckt werden, wenn ein Netzwerk-Socket bereit oder ein Timer abgelaufen ist.
Exceptions in Fibers richtig behandeln
Was passiert, wenn der Code in einer Fiber eine Exception wirft? Die Exception bleibt in der Fiber hängen, bis der Hauptcode resume() aufruft. Genau dort wird sie weitergereicht und kann mit einem normalen try/catch abgefangen werden.
<?php
$fiber = new Fiber(function () {
Fiber::suspend();
throw new RuntimeException('Fehler aus der Fiber');
});
$fiber->start();
try {
$fiber->resume();
} catch (RuntimeException $e) {
echo 'Im Hauptcode gefangen: ' . $e->getMessage() . PHP_EOL;
}
Wer Exceptions ignorieren würde, bekäme einen unbehandelten Fehler im Aufrufer. In größeren Setups mit vielen Fibers lohnt sich eine zentrale Wrapper-Funktion, die resume() und Exceptions kapselt, sodass eine einzelne kaputte Aufgabe nicht den ganzen Scheduler reißt. Ergänzend lässt sich Fiber::throw() nutzen, um eine Exception aktiv in die Fiber zu schicken, etwa beim Cancel einer Aufgabe oder bei einem Timeout.
flowchart TD
A[new Fiber + Closure] --> B[Fiber::start]
B --> C[Fiber-Code laeuft bis suspend]
C --> D[Hauptcode laeuft weiter]
D --> E[Fiber::resume]
E --> F[Fiber laeuft bis naechstem suspend oder Ende]
F --> G{terminated?}
G -->|Nein| E
G -->|Ja| H[Fiber::getReturn liefert Ergebnis]
Parallele HTTP-Calls mit Amp und Fibers
Wer einmal sehen will, was Fibers in Verbindung mit einem Async-Framework wirklich bringen, kann das mit Amp v3 ausprobieren. Die Bibliothek baut auf Fibers auf und lässt sich über Composer mit composer require amphp/http-client einbinden. Der entscheidende Punkt ist, dass jeder Request in seiner eigenen Fiber läuft und auf die HTTP-Response wartet, während andere Fibers weiterarbeiten dürfen.
<?php
require 'vendor/autoload.php';
use AmpHttpClientHttpClientBuilder;
use AmpHttpClientRequest;
use function Ampasync;
use function AmpFutureawait;
$urls = [
'https://example.com/a',
'https://example.com/b',
'https://example.com/c',
];
$client = HttpClientBuilder::buildDefault();
/* fuer jede URL eine Fiber starten, die unabhaengig auf I/O wartet */
$futures = array_map(
fn(string $url) => async(fn() => $client->request(new Request($url))->getStatus()),
$urls
);
/* Sammelt alle Ergebnisse, sobald sie verfuegbar sind */
$status = await($futures);
print_r($status);
/* Drei Requests laufen ueberlappend statt nacheinander */
Konzeptuell sieht der dahinterliegende Event-Loop in etwa so aus: while ($jobs) { naechstes_bereites_event_holen(); zugehoerige_fiber_resumen(); }. Jeder Aufruf von Amp\async() registriert eine Fiber im Loop, der I/O-Wartepunkt wird durch Amp\delay() oder einen wartenden HTTP-Call ausgelöst, und sobald die zugrundeliegende Socket-Operation bereit ist, weckt der Loop die Fiber wieder auf. Das ist der gleiche Mechanismus, den Goroutines in Go oder Coroutines in Kotlin auf einer höheren Sprachebene anbieten, in PHP eben über die Fiber-Klasse plus Framework-Stack. Mit Fiber::getCurrent() lässt sich aus einer Hilfsfunktion heraus prüfen, ob man gerade in einer Fiber läuft (Rückgabe null, wenn nicht), was Bibliotheken nützen, um sich an den jeweiligen Kontext anzupassen.
Wann brauche ich PHP Fiber in der Praxis?
Die ehrliche Antwort lautet: in den meisten Anwendungen direkt nie. Eine klassische REST-API oder ein WordPress-Plugin profitieren nicht davon, dass eine Funktion sich selbst pausieren kann. Der große Hebel entsteht erst dort, wo Wartezeiten an Datenbank, Netzwerk oder externen APIs entstehen. Ein Skript, das nacheinander 50 HTTP-Calls absetzt, kann mit einem Fiber-basierten Framework wie Amp die Wartezeiten überlappen und braucht statt 25 Sekunden nur noch zwei.
Direkt mit Fibers zu programmieren lohnt sich vor allem dann, wenn man selbst eine Library schreibt, die Async-Verhalten anbieten will, oder wenn man die Mechanik tiefer verstehen will. Für Anwendungs-Code ist die typische Reihenfolge: Erst prüfen, ob ein etablierter Async-Stack wie ReactPHP, Amp oder Swoole das Problem löst. Diese Frameworks abstrahieren die Fiber-Mechanik und liefern fertige Bausteine für HTTP-Clients, Worker-Pools und Event-Loops. Wer aus klassischem PHP heraus einsteigen möchte, kann zunächst Generatoren mit Closures kombinieren, um sich an die Denkweise zu gewöhnen, und erst später zu Fibers wechseln.
Fazit zu PHP Fiber
Mit PHP 8.1 hat die Sprache mit der PHP Fiber-Klasse einen wichtigen Baustein bekommen. Sie ermöglicht Cooperative Concurrency, ohne die strikten Einschränkungen von Generatoren und ohne den Komplexitätszuwachs echter Threads. Der Lifecycle aus start, suspend und resume ist schnell verstanden, der Datenaustausch über Argumente und Rückgabewerte sehr direkt. Wirklich brillieren Fibers im Zusammenspiel mit Async-Frameworks, die Event-Loops und I/O-Multiplexing on top liefern. Wer in Anwendungs-Code direkt mit Fibers arbeitet, sollte das bewusst tun und sich vorher fragen, ob nicht ein Framework die spannenderen Antworten liefert.
