Seite 3 - PHP

Ein klassischer PHP-FPM-Request gibt seinen kompletten Speicher am Ende automatisch frei, ein Swoole- oder RoadRunner-Worker dagegen lebt über tausende Requests hinweg im selben Prozess. Genau dieser Unterschied macht statischen Zustand, vergessene Closures und wachsende Caches zu einem echten Speicherleck, das über Stunden hinweg langsam den verfügbaren Arbeitsspeicher aufbraucht.

strict_types schaltet die automatische, stille Typkonvertierung von PHP für die aktuelle Datei ab: Ein String an einen int-Parameter, ein Float an einen int-Parameter oder ein falscher Rückgabetyp lösen sofort einen TypeError aus, statt unbemerkt in einen anderen Typ konvertiert zu werden, was Bugs Jahre früher sichtbar macht, direkt am Aufruf statt irgendwo tiefer im Code.

Ein gewöhnliches Array als Cache mit Objekten als Schlüsseln oder Werten verhindert, dass diese Objekte jemals vom Garbage Collector eingesammelt werden, solange der Cache selbst existiert, und genau das führt in lang laufenden Prozessen zu schleichenden Memory Leaks. WeakMap löst dieses Problem strukturell, indem der Cache selbst keinen Einfluss mehr auf die Lebensdauer der referenzierten Objekte nimmt.

Ein gewöhnliches PHP-Array ist intern eine geordnete Hashtabelle mit erheblichem Overhead pro Element, selbst wenn ausschließlich fortlaufende Integer-Schlüssel verwendet werden. SplFixedArray, SplStack, SplQueue und SplHeap bieten spezialisierte, speichereffiziente Datenstrukturen, die diesen Overhead bei großen, klar strukturierten Datenmengen spürbar reduzieren.

Globale Variablen und Singletons wirken bequem, machen PHP-Code aber schwer testbar, schwer parallelisierbar und in großen Projekten unberechenbar. Dieser Artikel zeigt, wie man Singleton::getInstance(), $GLOBALS und statische Registries schrittweise durch Dependency Injection ersetzt, ohne die Anwendung in einem Rutsch umzubauen.

Jedes gewachsene PHP-Projekt sammelt technische Schulden an, die Frage ist nie ob, sondern welche zuerst behoben werden. Dieser Artikel zeigt eine praktische Methode, technical debt anhand von Änderungshäufigkeit, Fehlerrisiko und Behebungsaufwand zu bewerten und daraus eine belastbare Reihenfolge abzuleiten.

Optimistic Locking und Pessimistic Locking sind zwei grundverschiedene Strategien, um zu verhindern, dass gleichzeitige Schreibzugriffe sich gegenseitig überschreiben. Wer versteht, wann eine Versionsspalte reicht und wann eine echte Datenbanksperre mit SELECT FOR UPDATE nötig ist, vermeidet sowohl stille Datenverluste als auch unnötige Performance-Einbußen durch übervorsichtiges Locking.

Die parallel Extension bringt echtes Multithreading nach PHP: Runtime, Future und Channel erzeugen isolierte Betriebssystem-Threads statt kooperativer Nebenläufigkeit. Wer die strikte Datenisolation zwischen Threads versteht und die Grenzen von Closures und Autoloading kennt, kann CPU-intensive Aufgaben spürbar beschleunigen, ohne auf externe Erweiterungen wie Swoole umzusteigen.

Wer SQL-Queries per String-Konkatenation baut, öffnet eine der ältesten und zugleich gefährlichsten Schwachstellenklassen der Webentwicklung. PDO Prepared Statements trennen Code und Daten strukturell und schließen SQL-Injection unabhängig vom Inhalt der Eingabe aus, vorausgesetzt sie werden korrekt konfiguriert und für Identifier, LIKE-Muster und IN-Listen richtig eingesetzt. Dieser Beitrag zeigt die vollständige technische Umsetzung mit PDO in PHP 8.4.

Wer Methoden und Funktionen weiterhin ueber Strings wie 'strlen' oder Arrays wie [$objekt, 'methode'] referenziert, verzichtet auf Typpruefung, IDE-Refactoring und verlaessliche Sichtbarkeitspruefung. Die First-Class-Callable-Syntax macht aus diesen Referenzen echte, vom Parser aufgeloeste Ausdruecke und schliesst damit eine der letzten stringbasierten Luecken der Sprache.