Heim > Artikel > Backend-Entwicklung > PHP-Erweiterung – Lebenszyklus- und Speicherverwaltung
1. PHP-Quellcodestruktur
PHP verfügt über zwei Kernsubsysteme, ZE (Zend Engine) und PHP Core.
ZE ist für das Parsen von PHP-Skripten in Maschinencode (auch als Token bekannt) verantwortlich Diese Maschinencodes werden im Prozessraum ausgeführt. ZE ist auch für die Speicherverwaltung, die Verwaltung des Variablenbereichs und die Planungsverwaltung von PHP-Funktionen verantwortlich.
PHP Core ist für die Kommunikation mit der SAPI-Schicht verantwortlich; PHP Core bietet außerdem eine einheitliche Kontrollschicht für Safe_Mode- und Open_basedir-Prüfungen; PHP Core bietet außerdem eine Streams-Schicht für Datei- und Netzwerk-E/A-Vorgänge. Darunter umfasst SAPI (Server Application Programming Interface) normalerweise Nginx, Apache, IIS, CLI, CGI und andere Hostumgebungen.
PHP-Erweiterung ermöglicht die Kapselung verschiedener gängiger Vorgänge basierend auf ZE und PHP Core, wie z. B. Lesen und Schreiben von MySQL, Redis, Memcache, SQLite usw., Parsen von JSON, XML-Dateien, Soap, Sokcet, Curl-Netzwerkprotokoll Kapselung, Verschlüsselung, Entschlüsselung, Komprimierung und Dekomprimierung usw., Bildverarbeitung usw. Einige Erweiterungen implementieren eine bestimmte Funktion von Grund auf, z. B. die Verwendung von C für die Kommunikation mit Redis gemäß dem Redis-Kommunikationsprotokoll. Einige Erweiterungen rufen vorhandene Bibliotheken im System auf, z. B. die GB-Erweiterung für die Bildverarbeitung, die auf dem System installiert werden muss selbst. Die entsprechende gd-Bibliothek.
78 Erweiterungen sind im PHP-Quellcode php-5.6.24/ext enthalten.
Kurz gesagt: ZE und PHP Core stellen die Grundarchitektur bereit, und EXT (Erweiterung) stellt verschiedene Operationen in der Benutzerdomäne bereit.
Am Beispiel des PHP-5.6.24-Quellcodes entspricht ZE dem Ordner php-5.6.24/Zend, PHP Core entspricht dem Ordner php-5.6.24/main und die Erweiterung entspricht dem Ordner php -5.6.24/ext.
2. Lebenszyklus der PHP-Erweiterung
Wenn PHP den SAPI-Befehl empfängt, initialisiert und startet es zunächst sein Kernel-Subsystem. Am Ende des Startvorgangs des Kernel-Subsystems beginnt PHP mit dem Laden Der Erweiterungscode initialisiert die Erweiterung. Zu diesem Zeitpunkt ruft PHP die Modulinitialisierungsroutine (MINIT) jedes Moduls auf.
MINIT (Modulinitialisierung)
PHP ruft MINIT-bezogene Routinen auf und gibt jeder Erweiterung die Möglichkeit, interne Variablen zu initialisieren, Ressourcen zuzuweisen, Ressourcenhandhabungshandles zu registrieren und ihre eigenen Funktionen bei ZE zu registrieren, um Skripte beim Aufrufen zu erleichtern Bei diesen Funktionen weiß ZE, welcher Code ausgeführt werden soll
RINIT (Request Initialization)
Nachdem die Modulinitialisierung abgeschlossen ist, wartet PHP auf die Anfrage von SAPI. Wenn die SAPI-Anfrage empfangen wird, sendet ZE das angeforderte PHP Das Skript erstellt eine laufende Umgebung und ruft die RINIT-Funktion (Request Initialization) jeder Erweiterung auf, wodurch jede Erweiterung die Möglichkeit hat, bestimmte Umgebungsvariablen festzulegen, Ressourcen entsprechend der Anforderung zuzuweisen oder andere Aufgaben, wie z. B. Audits, auszuführen.
Die hier erwähnten SAPI-Anfragen sind in zwei Kategorien unterteilt: Apache, IIS und andere ausgereifte Webserver-SAPIs. Beim Start führt PHP zuerst MINIT aus und wartet dann auf Seitenanfragen von Benutzern wird nach dem Empfang der Anfrage ausgeführt; eine andere Art von SAPI-Anfrage sind CGI- oder CLI-SAPIs. Wenn PHP diese Art von SAPI-Anfrage empfängt, führt es RINIT unmittelbar nach der Ausführung von MINIT aus.
Wenn die RINIT-Anfrage initialisiert wird, übernimmt ZE die Kontrolle zurück und übersetzt das aktuell angeforderte Skript in Token, die letztendlich Opcodes (Operationscodes) darstellen. Während der Ausführung von Opcodes erfordert ein Opcode die Ausführung eines bestimmten Eine Erweiterungsfunktion, was bedeutet, dass ZE die relevanten Parameter an die geänderte Funktion bindet und die Kontrolle vorübergehend zur Ausführung an die Funktion übergibt, bis die Funktion ausgeführt wird.
RSHUTDOWN(Request Shutdown)
Nachdem das PHP-Skript ausgeführt wurde, ruft PHP jede erweiterte Anforderungs-Shutdown-Funktion (RSHUTDOWN) auf, um letzte Aufräumarbeiten durchzuführen (z. B. das Speichern von Sitzungsvariablen auf der Festplatte). Als nächstes führt ZE einen Bereinigungsprozess (Garbage Collection) durch, bei dem effektiv jede Variable, die während der vorherigen Anfrage verwendet wurde, gelöscht wird.
MSHUTDOWN(Module Shutdown)
Wenn RSHUTDOWN abgeschlossen ist, wartet PHP weiterhin auf andere Dokumentanforderungen von SAPI oder ein Shutdown-Signal. Für SAPIs wie CGI und CLI gibt es keine „nächste Anfrage“, sodass die SAPI sofort mit dem Herunterfahren beginnt. Während des Herunterfahrens durchläuft PHP erneut jede Erweiterung, ruft die Funktion zum Herunterfahren des Moduls (MSHUTDOWN) auf und fährt schließlich sein eigenes Kernel-Subsystem herunter.
GINIT
Globale Variablen initialisieren
GSHUTDOWN
Globale Variablen freigeben
MINFO
Legen Sie die Informationen des phpinfo-Moduls fest, phpinfo muss die Konfiguration nivellieren Informationen zu jeder Erweiterung
// main/php.h #define PHP_MINIT ZEND_MODULE_STARTUP_N #define PHP_MSHUTDOWN ZEND_MODULE_SHUTDOWN_N #define PHP_RINIT ZEND_MODULE_ACTIVATE_N #define PHP_RSHUTDOWN ZEND_MODULE_DEACTIVATE_N #define PHP_MINFO ZEND_MODULE_INFO_N #define PHP_GINIT ZEND_GINIT #define PHP_GSHUTDOWN ZEND_GSHUTDOWN #define PHP_MINIT_FUNCTION ZEND_MODULE_STARTUP_D #define PHP_MSHUTDOWN_FUNCTION ZEND_MODULE_SHUTDOWN_D #define PHP_RINIT_FUNCTION ZEND_MODULE_ACTIVATE_D #define PHP_RSHUTDOWN_FUNCTION ZEND_MODULE_DEACTIVATE_D #define PHP_MINFO_FUNCTION ZEND_MODULE_INFO_D #define PHP_GINIT_FUNCTION ZEND_GINIT_FUNCTION #define PHP_GSHUTDOWN_FUNCTION ZEND_GSHUTDOWN_FUNCTION
3. PHP erweiterte Speicherverwaltung
Wenn ZE seine eigene interne Speicherverwaltung durchführt, verwendet es zusätzliche Flags, um zu identifizieren, ob eine bestimmte Speichervariable vorhanden ist ist Es ist persistent. ZE bereinigt ihn. Es ist jedoch am besten, den nicht persistenten Speicher innerhalb der Erweiterung selbst zu bereinigen, da der von der Erweiterung selbst zugewiesene nicht persistente Speicher lange Zeit nicht wiederverwendet wird und die damit verbundenen Ressourcen daher nicht lange freigegeben werden Zeit.