M

MLOG

ไทย

ปลดล็อกมัลติเธรดดิ้งที่แท้จริงใน JavaScript คู่มือฉบับสมบูรณ์นี้ครอบคลุม SharedArrayBuffer, Atomics, Web Workers และข้อกำหนดด้านความปลอดภัยสำหรับเว็บแอปพลิเคชันประสิทธิภาพสูง

JavaScript SharedArrayBuffer: เจาะลึกการเขียนโปรแกรมแบบทำงานพร้อมกันบนเว็บ

เป็นเวลาหลายทศวรรษที่ธรรมชาติการทำงานแบบเธรดเดียว (single-threaded) ของ JavaScript เป็นทั้งที่มาของความเรียบง่ายและคอขวดด้านประสิทธิภาพที่สำคัญ โมเดล Event Loop ทำงานได้อย่างสวยงามสำหรับงานส่วนใหญ่ที่ขับเคลื่อนด้วย UI แต่จะประสบปัญหาเมื่อต้องเผชิญกับการดำเนินการที่ต้องใช้การคำนวณสูง การคำนวณที่ใช้เวลานานสามารถทำให้เบราว์เซอร์ค้างได้ สร้างประสบการณ์ผู้ใช้ที่น่าหงุดหงิด แม้ว่า Web Workers จะเสนอทางออกบางส่วนโดยอนุญาตให้สคริปต์ทำงานในเบื้องหลัง แต่ก็มาพร้อมกับข้อจำกัดที่สำคัญในตัวเอง นั่นคือการสื่อสารข้อมูลที่ไม่มีประสิทธิภาพ

ขอแนะนำ SharedArrayBuffer (SAB) ซึ่งเป็นฟีเจอร์อันทรงพลังที่เปลี่ยนแปลงเกมโดยพื้นฐาน ด้วยการนำเสนอการแบ่งปันหน่วยความจำระดับต่ำอย่างแท้จริงระหว่างเธรดบนเว็บ เมื่อใช้ร่วมกับอ็อบเจกต์ Atomics SAB จะปลดล็อกยุคใหม่ของแอปพลิเคชันประสิทธิภาพสูงที่ทำงานพร้อมกันได้โดยตรงในเบราว์เซอร์ อย่างไรก็ตาม พลังอันยิ่งใหญ่มาพร้อมกับความรับผิดชอบอันใหญ่ยิ่ง—และความซับซ้อน

คู่มือนี้จะพาคุณเจาะลึกสู่โลกแห่งการเขียนโปรแกรมแบบทำงานพร้อมกันใน JavaScript เราจะสำรวจว่าทำไมเราถึงต้องการมัน SharedArrayBuffer และ Atomics ทำงานอย่างไร ข้อควรพิจารณาด้านความปลอดภัยที่สำคัญที่คุณต้องจัดการ และตัวอย่างการใช้งานจริงเพื่อช่วยให้คุณเริ่มต้น

โลกเก่า: โมเดลเธรดเดียวของ JavaScript และข้อจำกัด

ก่อนที่เราจะเข้าใจถึงคุณค่าของวิธีแก้ปัญหา เราต้องเข้าใจปัญหานั้นอย่างถ่องแท้เสียก่อน โดยปกติแล้ว การประมวลผล JavaScript ในเบราว์เซอร์จะเกิดขึ้นบนเธรดเดียว ซึ่งมักเรียกว่า "main thread" หรือ "UI thread"

The Event Loop

Main thread มีหน้าที่รับผิดชอบทุกอย่าง: การรันโค้ด JavaScript ของคุณ, การเรนเดอร์หน้าเว็บ, การตอบสนองต่อการโต้ตอบของผู้ใช้ (เช่น การคลิกและการเลื่อน) และการรันแอนิเมชัน CSS มันจัดการงานเหล่านี้โดยใช้ event loop ซึ่งประมวลผลคิวของข้อความ (tasks) อย่างต่อเนื่อง หากงานใดใช้เวลานานในการทำให้เสร็จ มันจะบล็อกคิวทั้งหมด ทำให้ไม่มีอะไรอื่นเกิดขึ้นได้—UI จะค้าง, แอนิเมชันจะกระตุก และหน้าเว็บจะไม่ตอบสนอง

Web Workers: ก้าวที่ถูกทาง

Web Workers ถูกนำมาใช้เพื่อบรรเทาปัญหานี้ Web Worker คือสคริปต์ที่ทำงานบนเธรดเบื้องหลังแยกต่างหาก คุณสามารถย้ายการคำนวณหนักๆ ไปยัง worker เพื่อให้ main thread เป็นอิสระในการจัดการกับส่วนติดต่อผู้ใช้

การสื่อสารระหว่าง main thread และ worker เกิดขึ้นผ่าน postMessage() API เมื่อคุณส่งข้อมูล ข้อมูลนั้นจะถูกจัดการโดย อัลกอริทึม structured clone ซึ่งหมายความว่าข้อมูลจะถูก serialized, คัดลอก และจากนั้น deserialized ในบริบทของ worker แม้ว่าจะมีประสิทธิภาพ แต่กระบวนการนี้มีข้อเสียที่สำคัญสำหรับชุดข้อมูลขนาดใหญ่:

ลองนึกภาพโปรแกรมตัดต่อวิดีโอในเบราว์เซอร์ การส่งเฟรมวิดีโอทั้งเฟรม (ซึ่งอาจมีขนาดหลายเมกะไบต์) ไปกลับไปยัง worker เพื่อประมวลผล 60 ครั้งต่อวินาทีจะมีค่าใช้จ่ายสูงเกินกว่าจะรับได้ นี่คือปัญหาที่ SharedArrayBuffer ถูกออกแบบมาเพื่อแก้ไขโดยเฉพาะ

ตัวเปลี่ยนเกม: ขอแนะนำ SharedArrayBuffer

SharedArrayBuffer คือบัฟเฟอร์ข้อมูลไบนารีดิบที่มีความยาวคงที่ คล้ายกับ ArrayBuffer ข้อแตกต่างที่สำคัญคือ SharedArrayBuffer สามารถแชร์ข้ามเธรดได้หลายเธรด (เช่น main thread และ Web Workers หนึ่งตัวหรือมากกว่า) เมื่อคุณ "ส่ง" SharedArrayBuffer โดยใช้ postMessage() คุณไม่ได้ส่งสำเนา แต่คุณกำลังส่งการอ้างอิงไปยัง บล็อกของหน่วยความจำเดียวกัน

ซึ่งหมายความว่าการเปลี่ยนแปลงใดๆ ที่เกิดขึ้นกับข้อมูลของบัฟเฟอร์โดยเธรดหนึ่ง จะปรากฏให้เห็นทันทีสำหรับเธรดอื่นๆ ทั้งหมดที่มีการอ้างอิงถึงมัน ซึ่งช่วยขจัดขั้นตอนการคัดลอกและ serialize ที่มีค่าใช้จ่ายสูง ทำให้สามารถแชร์ข้อมูลได้เกือบทันที

ลองคิดแบบนี้:

อันตรายของหน่วยความจำที่ใช้ร่วมกัน: ภาวะแข่งขัน (Race Conditions)

การแชร์หน่วยความจำแบบทันทีทันใดนั้นทรงพลัง แต่ก็นำมาซึ่งปัญหาคลาสสิกจากโลกของการเขียนโปรแกรมแบบทำงานพร้อมกัน นั่นคือ ภาวะแข่งขัน (race conditions)

ภาวะแข่งขันเกิดขึ้นเมื่อหลายเธรดพยายามเข้าถึงและแก้ไขข้อมูลที่ใช้ร่วมกันในเวลาเดียวกัน และผลลัพธ์สุดท้ายขึ้นอยู่กับลำดับการทำงานที่คาดเดาไม่ได้ ลองพิจารณาตัวนับง่ายๆ ที่เก็บไว้ใน SharedArrayBuffer ทั้ง main thread และ worker ต้องการเพิ่มค่าของมัน

  1. เธรด A อ่านค่าปัจจุบัน ซึ่งคือ 5
  2. ก่อนที่เธรด A จะสามารถเขียนค่าใหม่ได้ ระบบปฏิบัติการจะหยุดมันชั่วคราวและสลับไปที่เธรด B
  3. เธรด B อ่านค่าปัจจุบัน ซึ่งยังคงเป็น 5
  4. เธรด B คำนวณค่าใหม่ (6) และเขียนกลับไปยังหน่วยความจำ
  5. ระบบสลับกลับมาที่เธรด A มันไม่รู้ว่าเธรด B ทำอะไรไป มันทำงานต่อจากจุดที่ค้างไว้ คำนวณค่าใหม่ของมัน (5 + 1 = 6) และเขียน 6 กลับไปยังหน่วยความจำ

แม้ว่าตัวนับจะถูกเพิ่มค่าสองครั้ง แต่ค่าสุดท้ายคือ 6 ไม่ใช่ 7 การดำเนินการเหล่านี้ไม่เป็น อะตอม (atomic)—พวกมันสามารถถูกขัดจังหวะได้ ซึ่งนำไปสู่ข้อมูลที่สูญหาย นี่คือเหตุผลที่แท้จริงว่าทำไมคุณไม่สามารถใช้ SharedArrayBuffer ได้หากไม่มีคู่หูที่สำคัญของมัน นั่นคืออ็อบเจกต์ Atomics

ผู้พิทักษ์หน่วยความจำที่ใช้ร่วมกัน: อ็อบเจกต์ Atomics

อ็อบเจกต์ Atomics มีชุดของเมธอดแบบสถิต (static methods) สำหรับดำเนินการแบบอะตอมบนอ็อบเจกต์ SharedArrayBuffer การดำเนินการแบบอะตอม (atomic operation) คือการรับประกันว่าจะถูกดำเนินการทั้งหมดโดยไม่ถูกขัดจังหวะจากการดำเนินการอื่นใด มันจะเกิดขึ้นอย่างสมบูรณ์หรือไม่เกิดขึ้นเลย

การใช้ Atomics จะช่วยป้องกันภาวะแข่งขันโดยทำให้แน่ใจว่าการดำเนินการอ่าน-แก้ไข-เขียนบนหน่วยความจำที่ใช้ร่วมกันนั้นปลอดภัย

เมธอดหลักของ Atomics

มาดูเมธอดที่สำคัญที่สุดบางส่วนที่ Atomics มีให้

การซิงโครไนซ์: มากกว่าแค่การดำเนินการง่ายๆ

บางครั้งคุณต้องการมากกว่าแค่การอ่านและเขียนที่ปลอดภัย คุณต้องการให้เธรดประสานงานและรอซึ่งกันและกัน รูปแบบที่ไม่ควรทำที่พบบ่อยคือ "การรอแบบวนลูป" (busy-waiting) ซึ่งเธรดจะนั่งอยู่ในลูปที่ทำงานตลอดเวลาเพื่อตรวจสอบการเปลี่ยนแปลงในตำแหน่งหน่วยความจำ สิ่งนี้ทำให้สิ้นเปลืองรอบ CPU และเปลืองแบตเตอรี่

Atomics มีวิธีแก้ปัญหาที่มีประสิทธิภาพกว่ามากด้วย wait() และ notify()

การนำทั้งหมดมารวมกัน: คู่มือปฏิบัติ

เมื่อเราเข้าใจทฤษฎีแล้ว มาดูขั้นตอนการนำโซลูชันโดยใช้ SharedArrayBuffer ไปใช้งานจริง

ขั้นตอนที่ 1: ข้อกำหนดเบื้องต้นด้านความปลอดภัย - Cross-Origin Isolation

นี่คืออุปสรรคที่พบบ่อยที่สุดสำหรับนักพัฒนา ด้วยเหตุผลด้านความปลอดภัย SharedArrayBuffer จะใช้ได้เฉพาะในหน้าที่อยู่ในสถานะ cross-origin isolated เท่านั้น นี่เป็นมาตรการความปลอดภัยเพื่อลดช่องโหว่การคาดเดาการประมวลผล (speculative execution vulnerabilities) เช่น Spectre ซึ่งอาจใช้ตัวจับเวลาความละเอียดสูง (ซึ่งเป็นไปได้ด้วยหน่วยความจำที่ใช้ร่วมกัน) เพื่อล้วงข้อมูลข้ามต้นทาง (cross-origin)

ในการเปิดใช้งาน cross-origin isolation คุณต้องกำหนดค่าเว็บเซิร์ฟเวอร์ของคุณให้ส่ง HTTP headers สองตัวสำหรับเอกสารหลักของคุณ:


Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

การตั้งค่านี้อาจเป็นเรื่องท้าทาย โดยเฉพาะอย่างยิ่งหากคุณใช้สคริปต์หรือทรัพยากรของบุคคลที่สามที่ไม่ได้ให้ header ที่จำเป็น หลังจากกำหนดค่าเซิร์ฟเวอร์ของคุณแล้ว คุณสามารถตรวจสอบว่าหน้าของคุณถูกแยกหรือไม่โดยการตรวจสอบคุณสมบัติ self.crossOriginIsolated ในคอนโซลของเบราว์เซอร์ ซึ่งจะต้องเป็น true

ขั้นตอนที่ 2: การสร้างและแชร์บัฟเฟอร์

ในสคริปต์หลักของคุณ คุณสร้าง SharedArrayBuffer และ "view" บนมันโดยใช้ TypedArray เช่น Int32Array

main.js:


// ตรวจสอบ cross-origin isolation ก่อน!
if (!self.crossOriginIsolated) {
  console.error("หน้านี้ไม่ได้เป็น cross-origin isolated. SharedArrayBuffer จะไม่สามารถใช้งานได้");
} else {
  // สร้าง shared buffer สำหรับจำนวนเต็ม 32 บิตหนึ่งตัว
  const buffer = new SharedArrayBuffer(4);

  // สร้าง view บน buffer การดำเนินการ atomic ทั้งหมดจะเกิดขึ้นบน view นี้
  const int32Array = new Int32Array(buffer);

  // กำหนดค่าเริ่มต้นที่ index 0
  int32Array[0] = 0;

  // สร้าง worker ใหม่
  const worker = new Worker('worker.js');

  // ส่ง SHARED buffer ไปยัง worker นี่คือการส่งการอ้างอิง ไม่ใช่การคัดลอก
  worker.postMessage({ buffer });

  // รอรับข้อความจาก worker
  worker.onmessage = (event) => {
    console.log(`Worker รายงานว่าเสร็จสิ้นแล้ว ค่าสุดท้ายคือ: ${Atomics.load(int32Array, 0)}`);
  };
}

ขั้นตอนที่ 3: การดำเนินการแบบอะตอมใน Worker

worker จะได้รับบัฟเฟอร์และตอนนี้สามารถดำเนินการแบบอะตอมบนมันได้

worker.js:


self.onmessage = (event) => {
  const { buffer } = event.data;
  const int32Array = new Int32Array(buffer);

  console.log("Worker ได้รับ shared buffer แล้ว");

  // มาทำการดำเนินการแบบอะตอมกัน
  for (let i = 0; i < 1000000; i++) {
    // เพิ่มค่าที่แชร์ร่วมกันอย่างปลอดภัย
    Atomics.add(int32Array, 0, 1);
  }

  console.log("Worker เพิ่มค่าเสร็จแล้ว");

  // ส่งสัญญาณกลับไปยัง main thread ว่าเราทำเสร็จแล้ว
  self.postMessage({ done: true });
};

ขั้นตอนที่ 4: ตัวอย่างที่ซับซ้อนขึ้น - การบวกรวมแบบขนานพร้อมการซิงโครไนซ์

มาลองแก้ปัญหาที่สมจริงมากขึ้น: การบวกรวมอาร์เรย์ของตัวเลขขนาดใหญ่โดยใช้ worker หลายตัว เราจะใช้ Atomics.wait() และ Atomics.notify() เพื่อการซิงโครไนซ์ที่มีประสิทธิภาพ

shared buffer ของเราจะมีสามส่วน:

main.js:


if (self.crossOriginIsolated) {
  const NUM_WORKERS = 4;
  const DATA_SIZE = 10_000_000;

  // [status, workers_finished, result]
  // เราใช้จำนวนเต็ม 32 บิตหนึ่งตัวสำหรับผลลัพธ์
  const sharedBuffer = new SharedArrayBuffer(4 * 4); // 4 integers
  const sharedArray = new Int32Array(sharedBuffer);

  // สร้างข้อมูลสุ่มเพื่อประมวลผล
  const data = new Uint8Array(DATA_SIZE);
  for (let i = 0; i < DATA_SIZE; i++) {
    data[i] = Math.floor(Math.random() * 10);
  }

  const chunkSize = Math.ceil(DATA_SIZE / NUM_WORKERS);

  for (let i = 0; i < NUM_WORKERS; i++) {
    const worker = new Worker('sum_worker.js');
    const start = i * chunkSize;
    const end = Math.min(start + chunkSize, DATA_SIZE);
    
    // สร้าง view ที่ไม่ได้แชร์สำหรับส่วนข้อมูลของ worker
    const dataChunk = data.subarray(start, end);

    worker.postMessage({ 
      sharedBuffer,
      dataChunk // ส่วนนี้จะถูกคัดลอก
    });
  }

  console.log('Main thread กำลังรอให้ workers ทำงานเสร็จ...');

  // รอให้แฟล็กสถานะที่ index 0 เปลี่ยนเป็น 1
  // นี่ดีกว่าการใช้ while loop มาก!
  Atomics.wait(sharedArray, 0, 0); // รอถ้า sharedArray[0] เป็น 0

  console.log('Main thread ถูกปลุกแล้ว!');
  const finalSum = Atomics.load(sharedArray, 2);
  console.log(`ผลรวมสุดท้ายแบบขนานคือ: ${finalSum}`);

} else {
  console.error('หน้าเว็บไม่ได้เป็น cross-origin isolated');
}

sum_worker.js:


self.onmessage = ({ data }) => {
  const { sharedBuffer, dataChunk } = data;
  const sharedArray = new Int32Array(sharedBuffer);

  // คำนวณผลรวมสำหรับส่วนของ worker นี้
  let localSum = 0;
  for (let i = 0; i < dataChunk.length; i++) {
    localSum += dataChunk[i];
  }

  // เพิ่มผลรวมท้องถิ่นไปยังผลรวมที่แชร์ร่วมกันแบบอะตอม
  Atomics.add(sharedArray, 2, localSum);

  // เพิ่มตัวนับ 'workers finished' แบบอะตอม
  const finishedCount = Atomics.add(sharedArray, 1, 1) + 1;

  // ถ้านี่คือ worker ตัวสุดท้ายที่ทำงานเสร็จ...
  const NUM_WORKERS = 4; // ควรส่งค่านี้เข้ามาในแอปจริง
  if (finishedCount === NUM_WORKERS) {
    console.log('Worker ตัวสุดท้ายทำงานเสร็จแล้ว กำลังแจ้ง main thread');

    // 1. ตั้งค่าแฟล็กสถานะเป็น 1 (เสร็จสมบูรณ์)
    Atomics.store(sharedArray, 0, 1);

    // 2. แจ้ง main thread ซึ่งกำลังรออยู่ที่ index 0
    Atomics.notify(sharedArray, 0, 1);
  }
};

กรณีการใช้งานจริงและแอปพลิเคชัน

เทคโนโลยีที่ทรงพลังแต่ซับซ้อนนี้สร้างความแตกต่างได้ที่ไหน? มันยอดเยี่ยมในแอปพลิเคชันที่ต้องการการคำนวณหนักที่สามารถทำแบบขนานได้บนชุดข้อมูลขนาดใหญ่

ความท้าทายและข้อควรพิจารณาสุดท้าย

แม้ว่า SharedArrayBuffer จะเป็นการเปลี่ยนแปลงครั้งใหญ่ แต่ก็ไม่ใช่ยาวิเศษ มันเป็นเครื่องมือระดับต่ำที่ต้องการการจัดการอย่างระมัดระวัง

  1. ความซับซ้อน: การเขียนโปรแกรมแบบทำงานพร้อมกันนั้นเป็นที่ทราบกันดีว่ายาก การดีบักภาวะแข่งขัน (race conditions) และภาวะติดตาย (deadlocks) อาจเป็นเรื่องที่ท้าทายอย่างยิ่ง คุณต้องคิดแตกต่างออกไปเกี่ยวกับวิธีการจัดการสถานะของแอปพลิเคชันของคุณ
  2. ภาวะติดตาย (Deadlocks): ภาวะติดตายเกิดขึ้นเมื่อเธรดสองตัวหรือมากกว่าถูกบล็อกตลอดไป โดยแต่ละตัวกำลังรอให้อีกตัวปล่อยทรัพยากร สิ่งนี้สามารถเกิดขึ้นได้หากคุณใช้กลไกการล็อกที่ซับซ้อนไม่ถูกต้อง
  3. ค่าใช้จ่ายด้านความปลอดภัย: ข้อกำหนด cross-origin isolation เป็นอุปสรรคสำคัญ มันสามารถทำลายการทำงานร่วมกับบริการของบุคคลที่สาม, โฆษณา และเกตเวย์การชำระเงินได้ หากพวกเขาไม่รองรับ headers CORS/CORP ที่จำเป็น
  4. ไม่ใช่สำหรับทุกปัญหา: สำหรับงานเบื้องหลังง่ายๆ หรือการดำเนินการ I/O โมเดล Web Worker แบบดั้งเดิมด้วย postMessage() มักจะง่ายกว่าและเพียงพอ ควรใช้ SharedArrayBuffer ก็ต่อเมื่อคุณมีคอขวดที่ชัดเจนซึ่งเกิดจาก CPU และเกี่ยวข้องกับข้อมูลจำนวนมาก

บทสรุป

SharedArrayBuffer เมื่อใช้ร่วมกับ Atomics และ Web Workers ถือเป็นการเปลี่ยนแปลงกระบวนทัศน์สำหรับการพัฒนาเว็บ มันทำลายขอบเขตของโมเดลเธรดเดียว เปิดประตูสู่แอปพลิเคชันประเภทใหม่ที่ทรงพลัง, มีประสิทธิภาพ และซับซ้อนเข้ามาในเบราว์เซอร์ มันทำให้แพลตฟอร์มเว็บมีความทัดเทียมกับการพัฒนาแอปพลิเคชันเนทีฟมากขึ้นสำหรับงานที่ต้องใช้การคำนวณสูง

การเดินทางสู่ JavaScript แบบทำงานพร้อมกันนั้นท้าทาย ต้องใช้วิธีการที่เข้มงวดในการจัดการสถานะ, การซิงโครไนซ์ และความปลอดภัย แต่สำหรับนักพัฒนาที่ต้องการผลักดันขีดจำกัดของสิ่งที่เป็นไปได้บนเว็บ—ตั้งแต่การสังเคราะห์เสียงแบบเรียลไทม์ไปจนถึงการเรนเดอร์ 3 มิติที่ซับซ้อนและการคำนวณทางวิทยาศาสตร์—การเชี่ยวชาญ SharedArrayBuffer ไม่ใช่แค่ทางเลือกอีกต่อไป แต่เป็นทักษะที่จำเป็นสำหรับการสร้างเว็บแอปพลิเคชันรุ่นต่อไป