Bei einem kürzlich durchgeführten Projekt bin ich auf einige Situationen gestoßen, in denen ich häufig SQL-Abfragen verwenden, Dateien schreiben und Unteraufgaben aufteilen musste. Um den Programmdurchsatz zu verbessern, verwende ich einen Thread-Pool.
Erwägen Sie zu Beginn die Aufteilung der Benutzer entsprechend der Anzahl, da Oracle bei Datenbankabfragen eine Grenze von nicht mehr als 1.000 Abfragen für where in () hat. Erwägen Sie daher, alle 900 Benutzer in jeweils einen Slice aufzuteilen Slice ist eine Aufgabe und wird zur Verarbeitung an den Fix-Thread-Pool übergeben.
Aber jede Aufgabe hat zwei größere Unteraufgaben: das Abfragen von Gutscheinen und das Abfragen der Anzahl der abzugebenden Kommentare. Diese beiden Unteraufgaben erfordern eine große Anzahl von SQL-Abfragen, daher haben wir überlegt, diese beiden Unteraufgaben in Aufgaben zu kapseln zur Verarbeitung an den Thread-Pool übergeben. Da die Ausführung der Hauptaufgabe jedoch vom Ergebnis der Unteraufgabe abhängt, ist bei Verwendung desselben Thread-Pools nach der Übermittlung der Unteraufgabe die auszuführende Aufgabe in der Arbeitswarteschlange immer noch die Hauptaufgabe und die CPU Warten auf Future.get für die zuerst übermittelte Hauptaufgabe () kehrt zurück, die Unteraufgabe kann keine CPU-Ressourcen zur Ausführung erhalten und wartet in der Aufgabenwarteschlange, was dazu führt, dass das Programm auf den Tod wartet. Daher wurde der Thread-Pool von „Fix“ auf „Cache“ geändert, in der Hoffnung, dass die übermittelten Aufgaben CPU-Zeit erhalten und nicht die ganze Zeit in der Warteschlange warten müssen. Später verursachte dies auch Probleme, die im nächsten Artikel erläutert werden.
Wenn die Rechnungsdaten des Benutzers berechnet werden, muss das Vorlagencenter aufgerufen werden, um die E-Mail zu generieren, und die generierte E-Mail muss auf der Festplatte gespeichert werden. Dies sind zwei verschiedene IO-intensive Aufgaben, eine davon ist aktiviert Der Socket wartet, man wartet auf lokales IO. Wenn Sie weiterhin an den Cache-Thread-Pool senden, generiert der Thread-Pool für jede Aufgabe einen Thread, was viele Ressourcen verbraucht, und die CPU wechselt häufig den Thread, was den Durchsatz des Programms verringert. Erstellen Sie daher einen neuen Fix-Thread-Pool und senden Sie diese nachfolgenden Aufgaben zur Verarbeitung an den Fix-Thread-Pool. Der Thread-Pool verwendet eine feste Anzahl von Jobs zur Ausführung, wodurch das Programm unter verschiedenen Blockierungsbedingungen weiter ausgeführt werden kann und die Erstellung eines Jobs vermieden wird große Menge an Thread-Ressourcen.
Tatsächlich wurden im endgültigen Programm fünf Thread-Pools verwendet. Die Gründe für die hierarchische Verwendung sind wie folgt:
Um die Effizienz der Programmausführung zu verbessern, können Benutzer nach klassifiziert werden Zuerst die Sprache und dann in 900 Personen eingeteilt. Ein Teil wird fragmentiert, und jeder Teil der Aufgabe umfasst zwei Unteraufgaben, die häufig die Datenbank abfragen. Nach der Verarbeitung jedes Teils ist Netzwerk-E/A zum Erstellen von E-Mails und Festplatten-E/A zum Speichern von E-Mails erforderlich. Wenn derselbe Thread-Pool verwendet wird, warten nach der Übermittlung der von der übergeordneten Aufgabe erzeugten Unteraufgaben an den Fix-Thread-Pool verschiedene Arten von E/A-Vorgängen in der Aufgabenwarteschlange, da die Arbeitswarteschlange immer noch von der übergeordneten Aufgabe belegt ist den Systemdurchsatz verbessern. Nach der Übermittlung von Aufgaben auf niedrigerer Ebene an andere Thread-Pools haben die Aufgaben auf niedrigerer Ebene die Möglichkeit, sie sofort auszuführen und Netzwerk-E/A sowie Lese- und Schreibvorgänge auf der Festplatte durchzuführen, was die Betriebseffizienz verbessert.