CountQueuingStrategy.size() — Methode · JavaScript-Referenz

Signatur

CountQueuingStrategy.prototype.size(chunk)

Beschreibung

Die Methode size() einer CountQueuingStrategy berechnet die „Größe“ eines Chunks für die interne Warteschlange eines ReadableStream oder WritableStream. Sie liefert unabhängig vom Inhalt immer 1. Dadurch zählt der Stream einfach, wie viele Chunks gerade gepuffert sind – egal ob es sich um Strings, Objekte oder große Binärblöcke handelt.

Der Stream vergleicht die Summe aller size()-Werte mit der highWaterMark der Strategie. Daraus ergibt sich controller.desiredSize bzw. writer.desiredSize: Ist der Wert ≤ 0, sollte die Quelle keine weiteren Daten mehr erzeugen (Backpressure). Mit CountQueuingStrategy bedeutet eine highWaterMark von 5 also: „höchstens 5 Chunks puffern“.

In der Praxis ruft man size() selten direkt auf – der Stream macht das intern bei jedem enqueue() bzw. write(). Sinnvoll ist ein direkter Aufruf beim Testen, beim Debuggen oder wenn man die Strategie in einer eigenen Warteschlangenlogik wiederverwenden möchte. Sollen Chunks nach ihrer Bytegröße gewichtet werden, ist ByteLengthQueuingStrategy die bessere Wahl.

Parameter

Name	Typ	Default	Beschreibung
$chunk	any		Der Chunk, dessen Größe bestimmt werden soll. Wird von `CountQueuingStrategy` ignoriert – das Ergebnis ist immer `1`.

Beispiele

Direkter Aufruf: Größe ist immer 1

const strategy = new CountQueuingStrategy({ highWaterMark: 3 });

console.log(strategy.size('a'));
console.log(strategy.size({ id: 42, payload: 'x'.repeat(10_000) }));
console.log(strategy.size(new Uint8Array(1024)));
console.log(strategy.highWaterMark);

1 1 1 3

Backpressure in einem ReadableStream beobachten

const strategy = new CountQueuingStrategy({ highWaterMark: 2 });

const stream = new ReadableStream({
  start(controller) {
    // Jeder enqueue() zählt dank size() genau 1
    for (const msg of ['Hallo', 'Welt', 'Mehr']) {
      controller.enqueue(msg);
      console.log(`Nach "${msg}": desiredSize = ${controller.desiredSize}`);
    }
    controller.close();
  }
}, strategy);

Nach "Hallo": desiredSize = 1 Nach "Welt": desiredSize = 0 Nach "Mehr": desiredSize = -1

WritableStream: höchstens N Aufträge puffern

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

const sink = new WritableStream({
  async write(job) {
    await sleep(100); // langsame Verarbeitung simulieren
    console.log('Verarbeitet:', job.id);
  }
}, new CountQueuingStrategy({ highWaterMark: 2 }));

const writer = sink.getWriter();

for (let id = 1; id <= 4; id++) {
  await writer.ready; // wartet, wenn 2 Aufträge gepuffert sind
  console.log(`Schreibe ${id}, desiredSize vorher: ${writer.desiredSize}`);
  writer.write({ id });
}
await writer.close();

Schreibe 1, desiredSize vorher: 2 Schreibe 2, desiredSize vorher: 2 Schreibe 3, desiredSize vorher: 1 Verarbeitet: 1 Schreibe 4, desiredSize vorher: 1 Verarbeitet: 2 Verarbeitet: 3 Verarbeitet: 4

// Wichtig · Fallstricke

Inhalt wird ignoriert: Ein 100-MB-Chunk zählt genauso viel wie ein einzelnes Zeichen. Wer den Speicherverbrauch begrenzen will, sollte ByteLengthQueuingStrategy oder eine eigene Strategie mit size(chunk) verwenden.
Kein Bezug auf this: size ist als Getter definiert, der eine Funktion liefert; diese kann also problemlos herausgelöst werden (z. B. const { size } = strategy).
Wird einem Stream gar keine Strategie übergeben, verhält er sich im Prinzip wie eine CountQueuingStrategy mit highWaterMark: 1 (bei ReadableStream) bzw. 1 (bei WritableStream).
Byte-Streams: Für ReadableStream mit type: 'bytes' darf keine size()-Funktion angegeben werden – dort ist eine CountQueuingStrategy ungeeignet und führt zu einem RangeError.
Die tatsächliche Ausgabereihenfolge im WritableStream-Beispiel kann je nach Zeitverhalten leicht abweichen.
Kompatibilität: in Chrome, Edge, Firefox und Safari verfügbar; in Node.js global ab Version 18 (vorher über node:stream/web).

Siehe auch

ByteLengthQueuingStrategy.size() new CountQueuingStrategy() ContentIndex.add() GPUQueue.writeTexture() CSSNumericArray.keys()