ภาษาการเขียนโปรแกรม Javaและเครื่องเสมือน Java (JVM) ได้รับการออกแบบมาเพื่อรองรับการเขียนโปรแกรมแบบขนานการดำเนินการทั้งหมดเกิดขึ้นในบริบทของเธรดวัตถุและทรัพยากรสามารถเข้าถึงได้โดยเธรดแยกกันหลายเธรด โดยแต่ละเธรดมีเส้นทางการดำเนินการของตนเอง แต่สามารถเข้าถึงวัตถุใดๆ ในโปรแกรมได้ การเข้าถึงการอ่านและการเขียนวัตถุจะต้องได้รับการประสานงานอย่างเหมาะสม (หรือ " ซิงโครไนซ์ ") ระหว่างเธรด^{[ 1 ] [ 2 ]}การซิงโครไนซ์เธรดทำให้มั่นใจได้ว่าวัตถุจะถูกแก้ไขโดยเธรดเพียงเธรดเดียวในแต่ละครั้ง และป้องกันไม่ให้เธรดเข้าถึงวัตถุที่ได้รับการอัปเดตบางส่วนในระหว่างการแก้ไขโดยเธรดอื่น^{[ 2 ]}

การใช้งาน Java Virtual Machineส่วนใหญ่ มักทำงานเป็น กระบวนการเดียวในภาษาการเขียนโปรแกรม Java การเขียนโปรแกรมแบบขนานนั้นเกี่ยวข้องกับเธรด เป็นหลัก (หรือเรียกว่ากระบวนการแบบเบา ) การทำงานหลายกระบวนการจะเกิดขึ้นได้ก็ต่อเมื่อใช้ JVM หลายตัวเท่านั้น

เธรดใช้ทรัพยากรของกระบวนการร่วมกัน รวมถึงหน่วยความจำและไฟล์ที่เปิดอยู่ ซึ่งทำให้การสื่อสารมีประสิทธิภาพ แต่ก็อาจก่อให้เกิดปัญหาได้^{[ 2 ]}ทุกแอปพลิเคชันมีเธรดอย่างน้อยหนึ่งเธรดที่เรียกว่าเธรดหลัก เธรดหลักมีความสามารถในการสร้างเธรดเพิ่มเติมเป็น ออบเจ็กต์ RunnableหรือCallableอินเทอร์java.lang.Callableเฟซคล้ายกับjava.lang.Runnableตรงที่ทั้งสองได้รับการออกแบบมาสำหรับคลาสที่มีอินสแตนซ์ที่อาจถูกเรียกใช้งานโดยเธรดอื่น^{[ 3 ]}อย่างไรก็ตามjava.lang.Runnableไม่ส่งคืนผลลัพธ์และไม่สามารถโยนข้อยกเว้นแบบตรวจสอบได้^{[ 4 ]}

แต่ละเธรดสามารถกำหนดเวลา^{[ 5 ]}บนคอร์ CPU ที่แตกต่างกัน ^{[ 6 ]}หรือใช้การแบ่งเวลาบนโปรเซสเซอร์ฮาร์ดแวร์ตัวเดียว หรือการแบ่งเวลาบนโปรเซสเซอร์ฮาร์ดแวร์หลายตัว ไม่มีวิธีแก้ปัญหาทั่วไปสำหรับวิธีการแมปเธรด Java กับเธรดระบบปฏิบัติการดั้งเดิม การใช้งาน JVM แต่ละแบบสามารถทำสิ่งนี้ได้แตกต่างกัน

แต่ละเธรดจะเชื่อมโยงกับอินสแตนซ์ของคลาส เธรดjava.lang.Threadสามารถจัดการได้โดยตรงโดยใช้java.lang.Threadวัตถุ หรือโดยอ้อมโดยใช้กลไกนามธรรม เช่นjava.util.concurrent.Executorคลาสงาน^{[ 7 ]} Java มีคลาสงานดังต่อไปนี้:

• java.util.concurrent.ForkJoinTask<V>และลูกหลานของมัน:
  • java.util.concurrent.CountedCompleter<T>
  • java.util.concurrent.RecursiveAction(เป็นForkJoinTask<Void>)
  • java.util.concurrent.RecursiveTask<V>
• java.util.concurrent.FutureTask<V>
  • javafx.concurrent.Task<V>(จากJavaFX )

ในส่วนหนึ่งของProject Loomใน Java 21 ได้มีการนำ เธรดเสมือนมาใช้ ซึ่งช่วยให้สามารถเขียนโค้ดแบบปกติ บล็อก และซิงโครนัสได้ ในขณะที่สามารถปรับขนาดได้ถึงหลายล้านงาน^{[ 8 ] [ 9 ]}เธรด Java แบบคลาสสิกเรียกว่า "เธรดแพลตฟอร์ม" ซึ่งสอดคล้องกับเธรดของระบบปฏิบัติการโดยประมาณ แต่เธรดเสมือนของ Java มีน้ำหนักเบาและได้รับการจัดการโดย JVM โดยกำหนดเวลาให้ทำงานบนกลุ่มเธรดของระบบปฏิบัติการจริงขนาดเล็ก เธรดเสมือนยังคงเป็นแบบซิงโครนัสjava.lang.Threadแต่ถูกสร้างขึ้นด้วยเมธอดโรงงานเช่นofVirtual()แม้ว่าโค้ดจะยังคงเป็นแบบซิงโครนัสและบล็อก แต่เธรดของระบบปฏิบัติการจริงนั้นเป็นแบบอะซิงโครนัส เมื่อหยุดเพื่อรอ JVM จะแยกโค้ดออกจากเธรดจริง และทำงานอื่นๆ จนกว่าระบบปฏิบัติการจะส่งการแจ้งเตือนเหตุการณ์แบบอะซิงโครนัสเพื่อรับโค้ดต่อจากจุดที่หยุดไปจนเสร็จสิ้น

สามารถเริ่มเธรดได้โดยการระบุjava.lang.Runnableอ็อบเจ็กต์:

public class HelloRunnable implements Runnable { @Override public void run () { System . out . println ( "Hello from thread!" ); }public static void main ( String [] args ) { Thread t = new Thread ( new HelloRunnable ()); t.start ( ) ; } }

หรือโดยการสร้างคลาสย่อย:

public class HelloThread extends Thread { @Override public void run () { System . out . println ( "Hello from thread!" ); }public static void main ( String [] args ) { HelloThread t = new HelloThread (); t.start ( ) ; } }

การขัดจังหวะจะบอกเธรดว่าควรหยุดสิ่งที่กำลังทำอยู่และทำอย่างอื่น เธรดจะส่งการขัดจังหวะโดยการเรียกใช้เมธอดinterrupt()สำหรับjava.lang.Threadเธรดที่จะถูกขัดจังหวะ กลไกการขัดจังหวะถูกนำไปใช้โดยใช้แฟล็กภายในที่ระบุสถานะการขัดจังหวะ ซึ่งจะถูกตั้งค่าเมื่อมีการเรียกใช้เมธอดinterrupt()[ ^{10 ] [ 11 ] เมธอด}ใดๆ ที่ออกจากโปรแกรมโดยการโยนข้อยกเว้นjava.lang.InterruptedExceptionจะล้างสถานะการขัดจังหวะเมื่อทำเช่นนั้น แต่มีความเป็นไปได้ที่สถานะการขัดจังหวะอาจถูกตั้งค่าอีกครั้งทันทีโดยเธรดอื่นที่เรียกใช้interrupt()เมธอด

ในอดีต เธรดสามารถหยุดได้ทันทีโดยใช้stop()วิธีนี้ เมื่อเรียกใช้วิธีนี้java.lang.ThreadDeathจะมีการโยนข้อยกเว้น ซึ่งจะล้างเธรด วิธีนี้เป็นอันตรายเพราะอาจทำให้ข้อมูลอยู่ในสถานะเสียหาย และในที่สุดก็ถูกลบออกใน Java 20 ^{[ 12 ]}

วิธีการ นี้java.lang.Thread#join()อนุญาตjava.lang.Threadให้รอจนกว่าอีกกระบวนการหนึ่งจะเสร็จสมบูรณ์

ข้อยกเว้นที่ไม่ได้ถูกจัดการซึ่งถูกโยนโดยโค้ดจะทำให้เธรดหยุดทำงาน เธรดหลักจะพิมพ์ข้อยกเว้นไปยังคอนโซล แต่เธรดที่ผู้ใช้สร้างขึ้นจำเป็นต้องมีตัวจัดการที่ลงทะเบียนไว้เพื่อทำเช่นนั้น^{[ 13 ] [ 14 ]}

แบบจำลองหน่วยความจำของ Javaอธิบายว่าเธรดในภาษาการเขียนโปรแกรม Java โต้ตอบกันผ่านหน่วยความจำอย่างไร บนแพลตฟอร์มสมัยใหม่ โค้ดมักจะไม่ถูกประมวลผลตามลำดับที่เขียนไว้ คอมไพเลอร์โปรเซสเซอร์และระบบย่อยหน่วยความจำ จะจัดลำดับใหม่ เพื่อเหตุผลด้านประสิทธิภาพ ไม่มีการรับประกันความสามารถในการเรียงลำดับเชิงเส้นหรือแม้แต่ความสอดคล้องตามลำดับ^{[ 15 ]}เมื่ออ่านหรือเขียนฟิลด์ของออบเจ็กต์ที่ใช้ร่วมกัน สิ่งนี้ช่วยให้ คอมไพเลอ ร์ สามารถ เพิ่มประสิทธิภาพของหน่วยความจำ (เช่นการจัดสรรรีจิสเตอร์การกำจัดนิพจน์ย่อยทั่วไปและการกำจัดการอ่านที่ซ้ำซ้อน ) ผ่านการจัดลำดับการอ่านและการเขียนหน่วยความจำใหม่^{[ 16 ]}

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

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

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

การซิงโครไนซ์มีการใช้งานหลายรูปแบบ ที่น่าสังเกตเป็นพิเศษคือการกีดกันซึ่งกันและกันซึ่งมีเพียงเธรดเดียวเท่านั้นที่สามารถถือมอนิเตอร์ได้ในแต่ละครั้ง ดังนั้นการซิงโครไนซ์บนมอนิเตอร์หมายความว่าเมื่อเธรดหนึ่งเข้าสู่บล็อกที่ซิงโครไนซ์ซึ่งได้รับการป้องกันโดยมอนิเตอร์แล้ว จะไม่มีเธรดอื่นใดสามารถเข้าสู่บล็อกที่ได้รับการป้องกันโดยมอนิเตอร์นั้นได้จนกว่าเธรดแรกจะออกจากบล็อกที่ซิงโครไนซ์^{[ 2 ]}

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

การอ่านและเขียนข้อมูลในฟิลด์จะเป็นแบบเรียงลำดับเชิงเส้นได้ก็ต่อเมื่อฟิลด์นั้นเป็นแบบ volatileหรือฟิลด์นั้นได้รับการป้องกันด้วยล็อก เฉพาะ ที่ผู้อ่านและผู้เขียนทุกคนได้รับมา

เธรดสามารถบรรลุการกีดกันร่วมกันได้โดยการเข้าสู่บล็อกหรือเมธอดที่ซิงโครไนซ์ซึ่งได้รับล็อกโดยปริยาย^{[ 17 ] [ 2 ]}หรือโดยการได้รับล็อกที่ชัดเจน (เช่นReentrantLockจากjava.util.concurrent.locksแพ็กเกจ^{[ 18 ]} ) ทั้งสองวิธีมีนัยสำคัญเดียวกันสำหรับพฤติกรรมของหน่วยความจำ หากการเข้าถึงฟิลด์เฉพาะทั้งหมดได้รับการป้องกันโดยล็อกเดียวกัน การอ่านและการเขียนไปยังฟิลด์นั้นจะเป็นแบบเชิงเส้น (อะตอมิก)

JVM อาจใช้การล็อกในระหว่างการทำงานด้วย ซึ่งเรียกว่า "เทคนิคการล็อกแบบมีอคติแบบไม่ต้องเก็บข้อมูล" หรือ "การล็อกแบบมีอคติ" ^{[ 19 ]}

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

ตั้งแต่ Java 5 เป็นต้นมาvolatileการอ่านและการเขียนจะสร้างความสัมพันธ์แบบ happens-beforeคล้ายกับการได้มาและการปล่อย mutex ^{[ 20 ]}ความสัมพันธ์นี้เป็นเพียงการรับประกันว่าการเขียนหน่วยความจำโดยคำสั่งเฉพาะหนึ่งจะมองเห็นได้โดยคำสั่งเฉพาะอื่น

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

ฟิลด์ที่ประกาศไว้จะfinalไม่สามารถแก้ไขได้เมื่อได้รับการเริ่มต้นแล้ว^{[ 21 ]} ฟิลด์ ของวัตถุfinalจะได้รับการเริ่มต้นในตัวสร้าง ตราบใดที่thisการอ้างอิงยังไม่ถูกปล่อยจากตัวสร้างก่อนที่ตัวสร้างจะส่งคืนค่า ค่าที่ถูกต้องของfinalฟิลด์ใดๆ จะสามารถมองเห็นได้โดยเธรดอื่นๆ โดยไม่ต้องซิงโครไนซ์^{[ 22 ]}

Java มีคุณสมบัติความเป็นอะตอมิก (atomicity)java.util.concurrent.atomicซึ่งช่วยให้สามารถสร้างประเภทข้อมูลแบบไร้การล็อก ปลอดภัยต่อเธรด และมีการดำเนินการแบบอะตอมิก ในขณะเดียวกันก็หลีกเลี่ยงปัญหาเรื่องล็อก (lock-free synchronized)

ประเภทข้อมูลพื้นฐานและอาร์เรย์ของประเภทข้อมูลพื้นฐานจะมีประเภทอะตอมของตัวเอง (เช่นjava.util.concurrent.atomic.AtomicIntegerและjava.util.concurrent.atomic.AtomicIntegerArray) และสำหรับประเภทข้อมูลอ้างอิงjava.util.concurrent.atomic.AtomicReference<T>จะมีคลาสให้ใช้งาน

import java.util.concurrent.atomic.AtomicReference ;AtomicReference < String > ref = new AtomicReference <> ( "Hello..." ); ref . set ( "...world!" ); boolean success = ref . compareAndSet ( "...world!" , "Hello, world!" ); System . out . println ( ref . get ()); // "Hello, world!"

แทนที่จะใช้java.lang.Threadคลาสอื่นjava.util.concurrent.CompletableFuture<T>จะมีคลาสสำหรับการคำนวณแบบอะซิงโครนัส^{[ 23 ]}ซึ่งอาจมองได้ว่าคล้ายกับSystem.Threading.Tasks.Task<T>ในC#แม้ว่า Java จะไม่มีcoroutine ที่ชัดเจน เหมือนใน C# ก็ตาม

ตั้งแต่JDK 1.2 เป็นต้น มา Java ได้รวมชุดคลาสคอลเลกชันมาตรฐานไว้ด้วย ซึ่งก็คือเฟรมเวิร์กคอลเลกชันของ Java

Doug Leaซึ่งมีส่วนร่วมในการใช้งานเฟรมเวิร์กคอลเลกชันของ Java ได้พัฒนาแพ็ก เกจการทำงานพร้อมกัน ซึ่งประกอบด้วยฟังก์ชันพื้นฐานการทำงานพร้อมกันหลายรายการและคลาสที่เกี่ยวข้องกับคอลเลกชันจำนวนมาก^{[ 24 ]}งานนี้ได้รับการสานต่อและปรับปรุงเป็นส่วนหนึ่งของJSR 166 ซึ่งมี Doug Lea เป็นประธาน

JDK 5.0ได้เพิ่มและปรับปรุงโมเดลการทำงานพร้อมกันของ Java หลายประการ API การทำงานพร้อมกันที่พัฒนาโดย JSR 166 ก็ถูกรวมไว้ใน JDK เป็นครั้งแรกเช่นกันJSR 133ให้การสนับสนุนการดำเนินการอะตอมิกที่กำหนดไว้อย่างดีในสภาพแวดล้อมแบบมัลติเธรด/มัลติโปรเซสเซอร์

ทั้งJava SE 6และJava SE 7ได้นำเสนอ API JSR 166 เวอร์ชันที่ได้รับการปรับปรุง รวมถึง API ใหม่เพิ่มเติมอีกหลายรายการ

• การทำงานพร้อมกัน (วิทยาการคอมพิวเตอร์)
• รูปแบบการทำงานพร้อมกัน
• แบบจำลองแยก-ต่อ
• กำแพงความจำ
• โมเดลหน่วยความจำ
• ความปลอดภัยของเกลียว
• เธรดเซฟ
• Java ConcurrentMap

• บล็อก, โจชัว (2018). "Effective Java: Programming Language Guide" (ฉบับที่สาม). แอดดิสัน-เวสลีย์. ISBN 978-0134685991.
• Goetz, Brian; Peierls, Tim; Bloch, Joshua; Bowbeer, Joseph; Holmes, David; Lea, Doug (2006). Java Concurrency in Practice . Addison Wesley. ISBN 0-321-34960-1.
• Lea, Doug (1999). การเขียนโปรแกรมแบบขนานใน Java: หลักการออกแบบและรูปแบบ . Addison Wesley. ISBN 0-201-31009-0.

• บทช่วยสอนเรื่องการทำงานพร้อมกันในภาษา Java ของ Oracle
• หน้าเว็บโมเดลหน่วยความจำ Java ของ William Pugh
• บทช่วยสอนการทำงานพร้อมกันของ Java โดย Jakob Jenkov
• แอนิเมชั่นแสดงการทำงานพร้อมกันในภาษา Java โดย Victor Grazi
• ตัวตรวจสอบความปลอดภัยของเธรดสำหรับคลาส Java