Best practices לריבוי threads בפועל: Java — המוסכמות בעידן ה-virtual threads

«רוצים להקביל משימת batch עסקית ב-Java.» «ה-cache המשותף באפליקציית ה-Spring שלנו מתקלקל מדי פעם.» «ירשנו אפליקציית Swing ישנה שמלאה ב-new Thread.» — ל-Java יש multithreading מובנה בשפה מאז JDK 1.0, היא הבשילה לתיבת הכלים java.util.concurrent, ועם virtual threads ב-JDK 21 כתבה מחדש שוב את חוכמת התכנות התחרותי. דווקא כי ערכת הכלים כל כך עשירה, הכלי שאתם בוחרים הופך לאיכות התכנון עצמה.

מאמר זה הוא מהדורת Java של סדרת ה-multithreading בפועל. הוא מיועד למפתחים שכותבים מערכות עסקיות, משימות batch ויישומי שרת ב-Java, ממפה את עקרונות תכנון ה-multithreading — לעולם לא ליצור threads ישירות, להפחית מצב mutable משותף, משמעת locks, לתכנן איך עוצרים לפני כל דבר אחר — לכלים של Java (בעיקר מהדורת LTS, JDK 21 ואילך), ואוסף את הבחירות של עידן ה-virtual threads ואת ה-pitfalls הייחודיים ל-Java, על בסיס מקורות ראשוניים נכון לאוגוסט 2026. הוא כתוב כדי להיקרא בפני עצמו. אותם עקרונות כפי שהוחלו על שפות אחרות מכוסים במאמרי הלוויין «מהדורת .NET», «מהדורת C++» ו«מהדורת C».

1. המסקנה קודם

• אל תכתבו new Thread בקוד עסקי — אותה כלל חל גם ב-Java. מסרו משימות ל-ExecutorService ותנו לספרייה לנהל את מחזורי החיים של ה-threads.¹
• נתבו משימות שממתינות בעיקר ל-I/O ל-virtual threads. virtual threads, שהפכו רשמיים ב-JDK 21, משמשים אחד לכל משימה ואסור לשים אותם ב-pool לעולם. הגבילו מקביליות ב-Semaphore, לא בגודל pool.²³
• virtual threads הם כלי throughput, לא כלי להאצת חישוב. הקבלה CPU-bound עדיין עבודתם של platform threads בגודל של בערך מספר הליבות — pool קבוע או parallel stream, כמו קודם.³
• נעלו על אובייקט lock private final, או על ReentrantLock ייעודי. synchronized(this) ונעילה על אובייקט חשוף לציבור יכולים להתנגש עם קוד חיצוני. אם צריך רכישה עם timeout (tryLock), השתמשו ב-ReentrantLock.
• ב-JDK 21-23 הייתה בעיה שחסימה בתוך בלוק synchronized עשתה pin ל-virtual threads; JDK 24 (JEP 491) תיקן זאת. הבדילו בין אזהרות ישנות למציאות הנוכחית.³⁴
• volatile מבטיח visibility וסדר, לא אטומיות. השתמשו ב-AtomicInteger / LongAdder למונים, וב-locks למצב מורכב.⁵
• עצירה שיתופית באמצעות interruption היא הדרך הנכונה היחידה לעצור thread. Thread.stop / suspend / resume זורקים כעת UnsupportedOperationException. אל תבלעו InterruptedException — או שחזרו את הסטטוס או זרקו שוב.⁶
• עצרו ExecutorService בתבנית הדו-שלבית: shutdown → awaitTermination → shutdownNow. shutdownNow הוא best-effort (המימוש הסטנדרטי עובד דרך interruption), ולכן מניח שהמשימות מגיבות ל-interruption.¹
• ממשק Swing שייך בלעדית ל-EDT (Event Dispatch Thread). בקשו עדכונים מ-threads אחרים דרך SwingUtilities.invokeLater.⁷

2. למה multithreading קשה — race condition, deadlock ו-memory model

אם מרתיחים את הבעיות ש-multithreading מכניס, בלי קשר לשפה, יש שני סוגים.

race condition הוא באג שבו התוצאה תלויה בסדר שבו כמה threads מגיעים לקטע קוד מסוים. הדוגמה הקלאסית היא מונה משותף: הביטוי הבודד count++ מתפרק בפועל לשלושה צעדים — קרא, הוסף, כתוב בחזרה. אם שני threads נכנסים לשלושת הצעדים האלה באותו זמן, ההגדלה של thread אחד נדרסת ואובדת כשהאחר כותב בחזרה. התוצאה משתנה בכל הרצה, ואין דרך לחזות איזו תוצאה תקבלו.

sequenceDiagram
    accTitle: race condition קלאסי על מונה משותף
    accDescr: תרשים שמראה ששני threads קוראים count=10, מוסיפים מקומית ל-11, וכותבים בחזרה 11, כך ששתי הגדלות קרו אבל count נשאר 11.
    participant A as thread A
    participant M as משתנה משותף count
    participant B as thread B
    Note over M: count = 10
    A->>M: קריאה (10)
    B->>M: קריאה (10)
    A->>A: חיבור מקומי (11)
    B->>B: חיבור מקומי (11)
    A->>M: כתיבה בחזרה (11)
    B->>M: כתיבה בחזרה (11)
    Note over M: שתי הגדלות קרו,<br/>אבל count = 11 — ההגדלה של thread A אבדה

איור 1: race condition קלאסי שבו הגדלה על מונה משותף הולכת לאיבוד. אם thread אחר נשזר במהלך שלושת הצעדים של count++, הכתיבה האחרונה דורסת את האחרת

deadlock הוא מצב שבו שני threads ממתינים כל אחד ל-lock שהשני מחזיק, כך שאף אחד אינו יכול להתקדם. thread A מחזיק lock 1 וממתין ל-lock 2; thread B מחזיק lock 2 וממתין ל-lock 1 — זה לבדו מספיק כדי ששניהם ייעצרו לנצח.

flowchart LR
    accTitle: המתנה מעגלית של deadlock
    accDescr: תרשים שמראה thread A שמחזיק lock 1 וממתין ל-lock 2, ו-thread B שמחזיק lock 2 וממתין ל-lock 1.
    A["thread A<br/>מחזיק lock 1"] -->|"ממתין לשחרור lock 2"| B["thread B<br/>מחזיק lock 2"]
    B -->|"ממתין לשחרור lock 1"| A

איור 2: ההמתנה המעגלית של deadlock. ברגע שחצי ההמתנה יוצרים לולאה, כל thread בתוך הלולאה ההיא נעצר לנצח

שניהם תלויי-תזמון. שזירה שמופיעה פעם בעשרות אלפי הרצות במכונת פיתוח יכולה לקרות כל יום בשרת ייצור עם מספר ליבות ועומס שונים. «זה מפסיק להשתחזר ברגע שמחברים debugger» ו«זה נעלם כשהוספתי לוג» שניהם כי התצפית משנה את התזמון — התנהגות קלאסית לבאג race. בדיוק לכן כל עיקרון במאמר הזה מצביע לכיוון הפחתת המקומות שצריכים סנכרון, לפני שדואגים לסנכרן נכון.

2.1. הנחת יסוד ייחודית ל-Java —‏ memory model ו-happens-before

מעל זה, מה שמיוחד ל-Java הוא שאיך נראים נתונים משותפים מוגדר על ידי יחסי happens-before ב-Java Memory Model (JMM).

קריאה וכתיבה של משתנה משותף בלי סנכרון אינן הופכות ל«undefined behavior» בסגנון C++, אבל יכולות לגרום באופן לגיטימי לכך שערכים ישנים ממשיכים להיראות, או שכתיבות מופיעות שלא בסדר. שגיאת memory consistency שבה «לולאה צופה בדגל boolean, אבל הערך ש-thread אחר שינה אינו נראה לעולם» היא התנהגות שה-JMM מתיר, לא באג ב-JVM.⁵ הכלים שמגנים מפני זה הם המנגנונים שיוצרים יחסי happens-before — synchronized, volatile, והמחלקות ב-java.util.concurrent. השתמשו ב-concurrent collections נכון והספרייה מבטיחה לכם «יחס happens-before בין פעולת עדכון לשליפה עוקבת».⁸

במילים אחרות, ההנחיה המעשית של Java מסתכמת כך: אל תתחכמו עם משתנה משותף גולמי. השתמשו בכלים של java.util.concurrent לשיתוף, ותנו לספרייה ליצור את יחסי happens-before.

3. איך ליצור threads —‏ ExecutorService ו-virtual threads

3.1. הפרדת המשימה מאופן ההרצה

ExecutorService הוא מה שנושא את עקרון «אל תיצרו threads בעצמכם» ב-Java. הוא מפריד את העבודה (Runnable / Callable) מאופן הביצוע — כמה threads, איזה queue — ומשאיר יצירה, שימוש חוזר והשלכה של threads לספרייה.¹

מ-JDK 21 ואילך, בחירת אופן ההרצה הפכה לבחירה בינארית פשוטה.²³

flowchart TB
    accTitle: בחירת אופן ביצוע מ-JDK 21 ואילך
    accDescr: תרשים שמראה שמשימה I/O-bound הולכת ל-virtual threads אחד לכל משימה בלי pool, ומשימה CPU-bound הולכת ל-pool קבוע של platform threads או parallel stream, עם הגבלת מקביליות חיצונית ב-Semaphore.
    S["משימה שרוצים להריץ במקביל"] --> Q1{"מה מניע את המשימה?"}
    Q1 -->|"בעיקר המתנה ל-I/O<br/>קריאות HTTP, DB, קבצים"| VT["virtual threads<br/>Executors.newVirtualThreadPerTaskExecutor<br/>אחד לכל משימה, לעולם לא ב-pool"]
    Q1 -->|"חישוב CPU-bound"| PT["pool קבוע של platform threads<br/>Executors.newFixedThreadPool - בערך כמספר הליבות<br/>או parallel stream"]
    VT --> LIMIT["הגבילו מקביליות לשירותים חיצוניים<br/>ב-Semaphore, לא בגודל pool"]

איור 3: בחירת אופן ביצוע העבודה מ-JDK 21 ואילך. ציירו קודם את הקו — «שנו איך ממתינים ל-I/O, הקבילו למעבד» — ואז מסרו עבודה I/O-bound ל-virtual threads ועבודה CPU-bound ל-pool מקובל

יש הסתייגות אחת בצד ה-CPU-bound. Executors.newFixedThreadPool מגביל את מספר ה-threads, אבל ה-queue שלו אינו חסום. בשירות ארוך-חיים שבו ההגשות ממשיכות להקדים את העיבוד, רק ה-threads מוגבלים למספר הליבות — המשימות שנערמות ב-queue, והנתונים שלהן, ממשיכות לאכול זיכרון. בסוג כזה של התקנה, או השתמשו ב-ThreadPoolExecutor ישירות כדי להגדיר bounded queue פלוס מדיניות דחייה, או שימו בקרת כניסה כמו Semaphore בצד המגיש כדי שתוכלו להפעיל backpressure (אותו עיקרון כמו דיון ה-queues בסעיף 4).

3.2. אל תשתמשו לרעה ב-virtual threads

virtual threads הם threads קלים המנותקים מ-OS threads: במהלך פעולת blocking ב-JDK (I/O, lock, sleep וכדומה בספרייה הסטנדרטית) הם משחררים את ה-OS thread שלהם, ולכן JVM אחת יכולה להריץ מיליונים מהם. עם זאת, הם לא משחררים אותו לכל סוג חסימה. אם virtual thread נחסם בזמן שהוא מריץ קוד native (JNI) או foreign function, הוא נשאר pinned ל-carrier thread שלו. מה ש-JDK 24 (JEP 491, להלן) תיקן הוא pinning שנגרם מ-synchronized; pinning בגבול native נשאר, ולכן טעינת מספר גדול של virtual threads בפעולות שנחסמות זמן רב דרך JNI driver או API של התקן תמצה את ה-carrier threads. אבל כפי שהמדריך הרשמי מדגיש, הם לא «threads מהירים יותר». מהירות ביצוע הקוד אינה משתנה — מה שהם מספקים הוא scale (throughput).³

יש שלוש משמעויות לשימוש בהם.³

1. אל תשימו אותם ב-pool. virtual threads זולים וחד-פעמיים; «מספר המשימות = מספר ה-virtual threads» הוא המצב הנכון. הכנסת virtual threads ל-newFixedThreadPool היא טעות — השתמשו בצורה try (var executor = Executors.newVirtualThreadPerTaskExecutor()).
2. הגבילו מקביליות ב-Semaphore. בטאו אילוץ כמו «לכל היותר 10 חיבורים מקבילים ל-API חיצוני» ב-Semaphore, לא בגודל pool.
3. אל תשתמשו בהם לעבודה CPU-bound. platform threads בגודל של בערך מספר הליבות נשארים הכלי הנכון להקבלת חישוב, כמו קודם.

שימו לב שמה שרץ בתוך virtual thread הוא קוד סינכרוני רגיל. במקום לשכתב את הקוד כמו ש-async/await של .NET עושה, פילוסופיית התכנון מאחורי virtual threads היא לאפשר לכם להריץ קוד ישר «thread אחד לבקשה», בלי שינוי, בקנה מידה עצום.²

3.3. אי-הבנה נפוצה — «אין צורך ב-pool» חל רק על virtual threads

אל תקראו את משמעת «אל תשימו אותם ב-pool» כאילו «ב-Java אין דבר כזה thread pool (או שהוא לא יעיל)». המציאות הפוכה: ה-pools של Java הם חלק בשל של הספרייה הסטנדרטית מאז JDK 5 (2004). ה-pool הכללי הניתן לכוונון עדין ThreadPoolExecutor (נוצר דרך מפעלי Executors השונים), ForkJoinPool של work-stealing (המופע המשותף שלו, commonPool(), הוא יעד הביצוע ברירת המחדל ל-parallel streams ול-CompletableFuture), ו-ScheduledThreadPoolExecutor לביצוע מחזורי — אלה עדיין השחקנים המובילים לעבודה CPU-bound.

pool הוא ביסודו אופטימיזציה המיוסדת על «יצירה והחזקה של OS thread יקרות, לכן השתמשו בו שוב». virtual threads מבטלים את ההנחה הזו בכך שהם הופכים את עלות היצירה לקרובה לאפס, כך שאין עוד סיבה להשתמש בהם שוב — ההבנה המדויקת אינה שה-pool הפך ללא יעיל, אלא שה-threads הפכו קלים מספיק כדי שאופטימיזציית ה-pool תהיה מיותרת. ומתחת ל-virtual threads, ה-scheduler של ה-JDK מריץ קבוצת carrier threads (OS threads) שמספרם בערך מספר הליבות, כ-ForkJoinPool של work-stealing.² במילים אחרות, הצורה «לטפל בכמות עצומה של עבודה מקבילית ב-pool קטן של OS threads» נשמרת; רק ניהול ה-pool עבר מידי המפתח ל-JVM. הוגן לומר ש-Java מגיעה לאותו יעד כמו async/await של .NET, שמחזיר את ה-thread שלו ל-pool בנקודת await, בלי לשנות את צורת הקוד.

4. הפחתת מצב mutable משותף — חלוקה, immutability, concurrent collections ו-queues

תחרות נוצרת רק כשקיימים יחד «כמה threads» ו«נתונים משותפים mutable». מספר ה-threads נקבע לפי דרישות, ולכן מה שהתכנון יכול לחתוך הוא החלק המשותף. יש שלוש משפחות של טכניקות — חלוקה, הפיכה ל-immutable, ומסירת נתונים — והנה איך כותבים אותן ב-Java.

חלקו. לצבירה מקבילית, במקום שכל thread יכתוב למשתנה סכום משותף, תנו לכל thread לבנות תוצאה חלקית ואחדו אותן בסוף. reduce / collect של parallel stream מספקים בדיוק את הצורה הזו כמסגרת, ו-LongAdder, שנדון בהמשך, הוא גם מימוש של אסטרטגיית החלוקה — מפצל פנימית לתאים כדי לפזר תחרות, ומסכם אותם בקריאה. להפחית כמה פעמים כותבים למצב משותף בא לפני כתיבת סנכרון נכון.

הפכו ל-immutable. בנו נתונים עם record ו-immutable collections (List.copyOf / Map.copyOf) שלעולם אינם נכתבים מחדש אחרי הבנייה, ותוכלו לשתף אותם בלי סנכרון. לתצורה ולנתוני master, התבנית הסטנדרטית: כשצריך להחליף, בנו אובייקט חדש והחליפו הפניה volatile. עם זאת, «נראה לקריאה בלבד» ו«הוא immutable» הם דברים שונים. הגישות של record מחזירות את ההפניות הגולמיות של הרכיבים, והעתק של List.copyOf גם הוא shallow (אינו משכפל את אובייקטי האיברים), ולכן אם האיברים mutable, כל מי שמחזיק alias יכול לכתוב מחדש את התוכן, והתחרות נשארת. בטוח לשתף בלי סנכרון רק כשגרף האובייקטים כולו — כולל האיברים — immutable. אם מעורבים איברים mutable, או העבירו deep copy או דחפו גם את האיברים לכיוון record / טיפוסים immutable.

השתמשו בפעולות המורכבות על concurrent collections. לתבנית «צור אם חסר, ואז הכנס» של ConcurrentHashMap השתמשו ב-computeIfAbsent. השיטה הזו מבצעת את כל הקריאה באטומיות, ואם המפתח חסר, פונקציית המיפוי נקראת בדיוק פעם אחת בתוך אותה קריאה בודדת.⁸ האחריות שונה מ-ConcurrentDictionary.GetOrAdd של .NET (שה-factory שלו יכול לרוץ יותר מפעם אחת תחת תחרות) — נקודה שאנשים שעוברים בין שתי השפות מבלבלים בקלות. זה, עם זאת, אינו «בדיוק פעם אחת לאורך חיי המפתח». אם הפונקציה מחזירה null או זורקת, לא נרשם מיפוי, והפונקציה רצה שוב בקריאה עוקבת (אותו דבר אם הרשומה הוסרה אחרי הרישום). אם האתחול שלכם אינו סובל תופעות לוואי כפולות, תכננו כך שהפונקציה תצליח ותחזיר לא-null. כמחיר של להיות אטומית, חלק מהעדכונים מ-threads אחרים נחסמים בזמן שהחישוב רץ, ולכן שמרו על פונקציית המיפוי קצרה, ואל תעדכנו את אותה map מתוך הפונקציה (עדכון רקורסיבי שזוהה יכול לזרוק IllegalStateException).⁸

// התבנית הסטנדרטית למונה תדירות: computeIfAbsent + LongAdder
ConcurrentHashMap<String, LongAdder> freqs = new ConcurrentHashMap<>();
freqs.computeIfAbsent(key, k -> new LongAdder()).increment();

מסרו נתונים דרך queue. נתבו את זרימת הנתונים בין threads דרך BlockingQueue. עם ArrayBlockingQueue שקיבל קיבולת, put נחסם כשהוא מלא, ונותן backpressure טבעי — אותה צורה כמו ה-bounded channel במהדורת .NET. גם בעידן ה-virtual threads, התכנון הזה של ציור גבול ברור בין producer ל-consumer נשאר יעיל.

5. משמעת locks —‏ synchronized ו-ReentrantLock

5.1. על מה לנעול, ומה לא לעשות בזמן שמחזיקים lock

חשבו על יחידת ה-lock לא כ«קטע קוד» אלא כ«נתונים». ממפו אובייקט lock אחד לכל קבוצת נתונים mutable שרוצים להגן עליהם, וקחו את אותו lock בכל מקום שנוגע בנתונים האלה — המציאות של באג race היא בדרך כלל שהמיפוי הזה התפרק איפשהו. הימנעו מ-synchronized(this) ומ-synchronized(SomeClass.class), כי קוד חיצוני יכול לנעול את אותו אובייקט; במקום זאת, צמדו את הנתונים שרוצים להגן עליהם אחד-לאחד ל-private final Object lock = new Object(); שלעולם אינו נחשף החוצה.

עוד שתי משמעויות מעל זה. ראשית, אל תעשו שום דבר איטי, ושום דבר שנוגע בעולם החיצוני, בזמן שמחזיקים lock. I/O, קריאה ל-listeners, או הרצת קוד לא ידוע בזמן שעדיין מחזיקים את ה-lock גם מאריכים כמה זמן מחזיקים וגם מסכנים שהנקרא ינסה לקחת lock אחר, וליצור את ההמתנה המעגלית מאיור 2. שנית, קבעו את סדר הרכישה ל-locks מרובים. במקום שלוקחים שני locks או יותר, עשו כלל שכל thread לוקח אותם באותו סדר, ולמקומות שבהם אי אפשר להבטיח את הסדר הכינו נתיב «וותר ונסה שוב אם לא הצלחת» עם tryLock(timeout), שנדון בהמשך.

synchronized מספיק ל«exclusion קצר ופשוט». עברו ל-ReentrantLock ברגע שצריך את הדברים הבאים.

• רכישה עם timeout דרך tryLock(timeout) (הפיכת hang קבוע לכשל שאפשר לרשום ולטפל בו)
• מדיניות fairness, כמה Condition, או כשרוצים לפצל רכישה ושחרור של lock בין שיטות שונות

כשמשתמשים ב-ReentrantLock, לעולם אל תשברו את התבנית של try מיד אחרי lock() ו-unlock() בבלוק finally (ל-Java אין מקבילה ל-RAII של C++, ולכן התבנית הזו היא כל המשמעת).

5.2. virtual threads ו-pinning — מה השתנה ב-JDK 24

כש-virtual threads הוצגו לראשונה (JDK 21-23), היה אילוץ שבו חסימה בתוך בלוק synchronized עשתה pin ל-virtual thread על ה-OS thread שלו (הוא לא יכול היה לשחרר את ה-OS thread, ואיבד את יתרון ה-scale), והומלץ להחליף נקודות חסימה תכופות או ארוכות ב-ReentrantLock.³ האילוץ הזה נפתר כש-JEP 491 של JDK 24 כתב מחדש את מימוש ה-monitor, ו-synchronized כבר אינו עושה pin ל-virtual threads.⁴ אם אתם ב-JDK 24 ואילך, החלפה מכנית של synchronized כנגד pinning כבר אינה נחוצה. שווה לבדוק אם ההנחיות הישנות יותר בארגון שלכם עדיין תקועות באזהרת עידן JDK 21.

5.3. איפה האטומיים ו-volatile נכנסים

עדכונים אטומיים למשתנה בודד מטופלים על ידי AtomicInteger / AtomicLong / AtomicReference (או, לסטטיסטיקה שמגדילים רק בתדירות גבוהה, LongAdder העמיד בפני תחרות). volatile מבטיח visibility וסדר (happens-before), לא אטומיות לפעולות מורכבות.⁵ אותה מסקנה כמו במהדורות .NET ו-C++ מחזיקה גם ב-Java: השתמשו באטומיים לדגלים ולערכים בודדים, ב-locks למצב מורכב, ואל תנסו לגרום ל-volatile לעשות זאת לבד.

6. תכנון איך עוצרים — interruption כשפה משותפת

6.1. כללי הנימוס של interrupt

עצירה וביטול ב-Java מאוחדים סביב interruption. t.interrupt() מגדיר את סטטוס ה-interrupt של ה-thread היעד, ואם היעד חסום ב-sleep / wait / join או דומה, הוא זורק InterruptedException כדי להעיר אותו מיד (ואז סטטוס ה-interrupt מנוקה).⁶ Thread.stop / suspend / resume, המנגנונים הכפויים של העבר, אינם בטוחים ביסודם, ולכן קריאה אליהם כעת מסתיימת ב-UnsupportedOperationException.⁶

flowchart TB
    accTitle: עצירה שיתופית באמצעות interruption
    accDescr: תרשים שמראה שקריאה ל-t.interrupt מגדירה את סטטוס ה-interrupt, thread שמחשב בודק Thread.interrupted בלולאה, ו-thread חסום ב-sleep/wait/join מתעורר עם InterruptedException; אחרי catch הבחירה היא לסיים או לשחזר את הסטטוס.
    OWNER["הקורא עוצר אותו - קורא ל-t.interrupt"] --> ST["סטטוס ה-interrupt מוגדר"]
    ST --> A["thread שמחשב:<br/>בודק Thread.interrupted בלולאה"]
    ST --> B["חסום ב-sleep / wait / join:<br/>InterruptedException נורה ומעיר מיד<br/>הסטטוס מנוקה"]
    A --> E["מנקה ומסיים בעצמו"]
    B --> C{"מה ה-catch עושה?"}
    C -->|"יכול לסיים בעצמו"| E
    C -->|"לא יכול לסיים - למשל בתוך ספרייה"| R["Thread.currentThread.interrupt<br/>משחזר את הסטטוס ומשאיר את האות"]
    R --> E

איור 4: עצירה שיתופית באמצעות interruption. בליעת InterruptedException גורמת לאות העצירה להיעלם — ברגע שתפסתם אותו, הבחירה היא «לסיים» או «לשחזר»

יש משמעת אחת בלבד שצריך לזכור בפועל: אל תכתבו קוד שתופס InterruptedException ואינו עושה דבר. אם אפשר לסיים באחריות שלכם, סיימו שם; אם לא, שחזרו את הסטטוס ב-Thread.currentThread().interrupt() והעבירו את האות לקורא (ראו את שאלות הנפוצות).

6.2. ה-shutdown הדו-שלבי של ExecutorService

ממשקי ה-shutdown של ExecutorService יושבים מעל מודל ה-interruption. shutdown() מפסיק לקבל משימות חדשות ונותן למשימות שכבר הוגשו לרוץ עד השלמה; shutdownNow() מנסה לעצור משימות רצות. כמפרט ממשק זה best-effort, ומתועד במפורש שמימוש סטנדרטי (כמו ThreadPoolExecutor) מבטל בדרך כלל דרך Thread.interrupt() — כלומר משימה שאינה מגיבה ל-interruption לא תיעצר גם עם shutdownNow, ואם משתמשים במימוש Executor מותאם צריך לבדוק בתיעוד שלו איך הוא מבטל (האם הוא שולח interrupt בכלל).¹ תבנית העצירה הסטנדרטית שמוצגת בתיעוד הרשמי היא התבנית הדו-שלבית הבאה.¹

/** אמת כשה-shutdown הושלם. אל תמשיכו לשחרור משאבים משותפים כל עוד זה שקר. */
boolean shutdownAndAwaitTermination(ExecutorService pool) {
    pool.shutdown();                    // שלב 1: להפסיק לקבל משימות חדשות ולהמתין להשלמה
    try {
        if (!pool.awaitTermination(60, TimeUnit.SECONDS)) {
            // שלב 2: לבקש ביטול. משימות שהורדו לפני שהרצו
            // מוחזרות, לכן סמנו את ה-Future שלהן כמבוטלות כדי להעיר ממתינים ל-get()
            pool.shutdownNow().forEach(r -> {
                if (r instanceof Future<?> f) f.cancel(false);
            });
            if (!pool.awaitTermination(60, TimeUnit.SECONDS)) {
                System.err.println("Pool did not terminate");
                return false;           // ה-shutdown לא הושלם. דווחו בצורה שניתן להבחין בה מהצלחה
            }
        }
        return true;
    } catch (InterruptedException ex) {
        pool.shutdownNow().forEach(r -> {
            if (r instanceof Future<?> f) f.cancel(false);
        });
        Thread.currentThread().interrupt();   // שחזרו גם את סטטוס ה-interrupt של ה-thread הזה
        return false;                   // גם הנתיב הזה עלול להשאיר את ה-shutdown חלקי
    }
}

flowchart TB
    accTitle: shutdown דו-שלבי של ExecutorService
    accDescr: תרשים שמראה shutdown שמפסיק לקבל משימות, המתנה ב-awaitTermination, ואם פג הזמן shutdownNow ששולח interrupt, ואז המתנה נוספת או רישום כחריגה.
    S["shutdown<br/>מפסיק לקבל משימות חדשות"] --> W1{"awaitTermination<br/>ממתין להשלמה"}
    W1 -->|"מסיים בתוך המועד"| DONE["ה-shutdown הושלם"]
    W1 -->|"פג הזמן"| NOW["shutdownNow<br/>שולח interrupt למשימות רצות<br/>האם יגיב תלוי במשימה"]
    NOW --> W2{"awaitTermination<br/>ממתין שוב"}
    W2 -->|"משלים"| DONE
    W2 -->|"עדיין לא סיים"| LOG["רשמו כחריגה<br/>חשדו במשימה שמתעלמת מ-interrupt"]

איור 5: ה-shutdown הדו-שלבי של ExecutorService. תכנון מדורג של «המתן בנימוס → בקש דרך interruption → אם עדיין לא סיים, צפה בזה כחריגה»

יש מגבלה אחת בביטול ה-Runnable ש-shutdownNow() מחזיר. מה שחוזר הוא האובייקט שישב ב-queue הביצוע — ל-submit פשוט זה בדיוק ה-FutureTask שנמסר לקורא, אבל למשימות שהוגשו דרך wrapper כמו ExecutorCompletionService זה ה-wrapper שבתוך ה-queue, אובייקט שונה מ-Future של הקורא. בתצורה הזו, הביטול למעלה לא ישלים את ה-Future של הקורא, לכן תכננו לשמור רשימת Future משלכם בזמן ההגשה ולבטל אותם ב-shutdown (או להחזיר את המשימות שהורדו לבעליהן).

close() (AutoCloseable), זמין מ-JDK 19 ואילך, אורז «קרא ל-shutdown והמתן להשלמה» לצורה שאפשר לכתוב עם try-with-resources, ו-try (var executor = ...) בשילוב עם newVirtualThreadPerTaskExecutor של virtual threads הוא הצורה הבסיסית המודרנית.¹ עם זאת, close() אינו תחליף לתבנית הדו-שלבית למעלה. כי הוא ממתין להשלמה בלי timeout, אם אפילו משימה אחת אינה מגיבה ל-interruption או לעולם אינה מסיימת, ה-thread שמנסה לסגור אותו נחסם לנצח. זה כלי שמתאים להיקפים שבהם המשימות סופיות ומבטיחות לרוץ עד השלמה (הגישו שם, המתינו שם); למקומות כמו נתיב ה-shutdown של יישום, שבהם רוצים שתמיד יסתיים בתוך זמן חסום, השתמשו בתבנית הדו-שלבית עם timeout במקום. ביטול משימה בודדת נעשה גם כן דרך interruption, עם Future.cancel(true).

7. ה-UI thread — ה-EDT של Swing

יישומי שולחן עבודה, בלי קשר לשפה או למסגרת, פועלים לפי הכלל שממשק המשתמש שייך בלעדית ל-thread שמנהל אותו. ב-Swing, ה-thread הבלעדי הזה הוא Event Dispatch Thread (EDT): שיטות רכיבי Swing, ככלל, אינן thread-safe, ונגיעה בהן מכמה threads מזמינה thread interference ושגיאות memory consistency. בקשו עדכוני מסך מ-threads אחרים דרך SwingUtilities.invokeLater אל ה-EDT, ולהפך, כי הרצת פעולות ארוכות על ה-EDT מקפיאה את הממשק, דחפו עבודה כבדה ל-worker thread דרך SwingWorker או דומה.⁷ JavaFX פועל באותה צורה: עדכוני UI מתבקשים על ה-application thread דרך Platform.runLater.

8. אימות וניפוי — thread dumps כנשק

אי אפשר לצפות שבדיקות ימצאו באגי race. בדיקות רגילות סופרות כהצלחה הרצה שבה במקרה לא קרתה תחרות. חשבו על ההגנה בשלוש שכבות.

קו ההגנה הראשון הוא תכנון. ב-review, בדקו בטבלה: אילו נתונים mutable משותפים, איזה lock מגן על כל פריט (המיפוי מסעיף 5.1), האם סדר רכישת ה-locks ייחודי, האם בלוק catch כלשהו בולע InterruptedException, והאם נתיב העצירה (shutdown/interruption) מגיע לכל משימה.

שנית, נצלו היטב thread dumps. ל-Java יש כלי סטנדרטי ללכידת «מצב כל thread ברגע הקפוא הזה»: jstack (או jcmd <pid> Thread.print) מדפיס stack traces, והאפשרות -l מוסיפה גם מידע על locks.⁹ שימו לב שפורמט ה-dump המסורתי הזה הוא ל-platform threads; הוא אינו כולל את ה-virtual threads של היישום שלכם. כשעוקבים אחרי בקשה חסומה בתצורה שמשתמשת ב-virtual threads (סעיף 3), השתמשו ב-jcmd <pid> Thread.dump_to_file -format=json <file>, שיכול לדלוף גם virtual threads.² ההליך הבסיסי לחקירת hang הוא לקחת שני או שלושה dumps בהפרש של כמה שניות ולהצליב על איזה lock כל thread בטל ממתין, ומי מחזיק ב-lock הזה. אם תרשמו timeouts של tryLock(timeout) (סעיף 5.2), תוכלו אפילו לאוטומט את הטריגר ללקיחת dump.

שלישית, נערו תחת עומס. בדיקת עומס — הרצה ארוכה עם מקביליות גדולה ממספר הליבות, ערבוב סדר עיבוד, הזרקת השהיות מלאכותיות — היא דרך מעשית להעלות את הסיכוי למשוך את «הפגיעה» של race condition במכונת פיתוח. הריצו לפחות בדיקה אחת בנפח נתונים ומספר threads של קנה מידה ייצור לפני שחרור.

9. לאן הולכת התחרותיות של Java —‏ Structured Concurrency

מבט מהיר חצי צעד קדימה, לסיום. בנוי על הנחת ה-virtual threads, Structured Concurrency (StructuredTaskScope) — שמתייחס לכמה משימות-משנה כיחידת עבודה אחת ומבנה הפצת כשל וביטול — בפיתוח, ונכון לאוגוסט 2026 עדיין תכונת preview. הוא עודכן לצורה מבוססת StructuredTaskScope.open() ב-preview החמישית של JDK 25 (JEP 505), וממשיך ל-preview שישית (JEP 525) ב-JDK 26 הנוכחי.¹⁰¹¹ בינתיים Scoped Values, שיתוף הקשר immutable שפותר את הבעיות של ThreadLocal, הושלם ב-JDK 25.¹² עקרונות המאמר הזה — גבולות משימה ברורים, שיתוף immutable, עצירה שיתופית — מיושרים גם עם הכיוון שאליו ה-API החדשים האלה הולכים.

10. סיכום — רשימת הבדיקה של Java

1. האם נשאר new Thread כלשהו בקוד עסקי (האם הוא בנוי על ExecutorService / virtual threads)?
2. האם עבודה I/O-bound ועבודה CPU-bound מנותבות למנגנוני ביצוע שונים (הענף באיור 3)?
3. האם virtual threads אינם ב-pool, והאם מקביליות מוגבלת ב-Semaphore?
4. האם נתונים משותפים immutable (record / List.copyOf), או בנויים על הכלים של java.util.concurrent?
5. האם אין synchronized(this) או נעילה על אובייקט חשוף לציבור?
6. האם משתמשים בפעולות המורכבות של ConcurrentHashMap (computeIfAbsent וכו’) ושומרים על פונקציית המיפוי קצרה?
7. האם לא מצפים לאטומיות מ-volatile (האם מונים משתמשים במחלקות Atomic / LongAdder)?
8. האם אין אפילו בלוק catch אחד שבלע InterruptedException?
9. האם עצירת ExecutorService עוקבת אחרי התבנית הדו-שלבית עם timeout (והאם מקומות שמשתמשים ב-close() מוגבלים להיקפים שבהם השלמת משימות מובטחת)?
10. האם עדכוני UI של Swing/JavaFX מרוכזים על ה-EDT / application thread?

Java היא אחת השפות המצוידות ביותר בכלי concurrency, והגעת ה-virtual threads פתחה נתיב להרחבת קוד סינכרוני ישר בלי לשכתב אותו. בדיוק לכן תפיסה נכונה של חלוקת העבודה בין הכלים — איזה ל-throughput, איזה ל-exclusion, ומה מסמן עצירה — היא מהות תכנון ה-multithreading ב-Java.

מאמרים קשורים

• שיטות עבודה מומלצות לרב־תהליכוניות בפועל: מהדורת .NET — מה להחליט לפני שמוסיפים תהליכונים
• שיטות עבודה מומלצות לרב־תהליכוניות בפועל: מהדורת C++ — ביטול תאונות במבנה עם RAII ו-jthread
• פרקטיקות מומלצות לריבוי תהליכונים: מהדורת C — כתיבה בטוחה בדרך של Win32 API
• async/await ב-C#: טבלת החלטה ל-Task.Run ו-ConfigureAwait

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת ב-design reviews של multithreading למערכות עסקיות ולעיבוד batch ב-Java, בחקירת שורש של פגמי concurrency כמו קלקול מצב משותף ותסמיני «לפעמים לא נעצר / נתקע» (ניתוח thread dumps), ובייעוץ טכני על אימוץ virtual threads.

• ייעוץ טכני וסקירת תכנון
• חקירת תקלות ואיתור גורמים
• יצירת קשר

מקורות

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

אם יש עכשיו virtual threads, האם כבר לא צריך thread pool (ExecutorService)?

זה תלוי בתרחיש. virtual threads הם מנגנון להרצת מספר עצום של משימות שבהן שולטת המתנה ל-I/O; הם לא מאיצים את הקוד, הם מעלים throughput. לעבודה I/O-bound השתמשו ב-virtual thread אחד לכל משימה (Executors.newVirtualThreadPerTaskExecutor) ואל תשימו virtual threads ב-pool לעולם. לעומת זאת, להקבלה של חישוב שממצה את המעבד, pool של platform threads המוגבל בערך למספר הליבות (או parallel stream) עדיין הכלי הנכון, כמו קודם. ואם רוצים להגביל את מספר החיבורים המקבילים לשירות חיצוני, ההמלצה בעידן ה-virtual threads היא להגביל ב-Semaphore ולא בגודל pool.

במה להשתמש, synchronized או ReentrantLock?

ל-exclusion קצר ופשוט synchronized מספיק, והקוד נשאר תמציתי. בחרו ReentrantLock כשצריך יכולות כמו רכישה עם timeout דרך tryLock, מדיניות fairness, או כמה Condition. יש הסתייגות היסטורית בשילוב עם virtual threads: ב-JDK 21-23 הייתה בעיה שחסימה בתוך בלוק synchronized הצמידה (pin) את ה-virtual thread ל-OS thread שלו, ולכן הומלץ להחליף נקודות חסימה תכופות או ארוכות ב-ReentrantLock. JDK 24 (JEP 491) כתב מחדש את מימוש ה-monitor ופתר את האילוץ הזה. מ-JDK 24 ואילך אין צורך להחליף synchronized מסיבות pinning.

האם הוספת volatile הופכת משהו ל-thread-safe?

לא. volatile של Java יוצר יחס happens-before בין כתיבה למשתנה הזה לקריאה ממנו, ומבטיח visibility (שהכתיבה האחרונה נראית ל-threads אחרים) וסדר, אבל אינו מבטיח אטומיות לפעולה מורכבת כמו "קרא, חשב, כתוב בחזרה". הגדילו מונה volatile int ב-++ מכמה threads והחיבורים הולכים לאיבוד. השתמשו ב-AtomicInteger / AtomicLong (או LongAdder לצבירה בתדירות גבוהה) למונים, וב-lock כשמגינים על כמה משתנים יחד. volatile מתאים כמעט רק במצבים כמו דגל מצב פשוט — שבהם thread אחד כותב והאחרים רק קוראים.

מותר לתפוס InterruptedException ולהתעלם ממנו?

לא. interruption הוא אות העצירה והביטול הסטנדרטי של Java, ובליעתו יוצר thread שלא ייעצר. ברגע ש-InterruptedException נזרק סטטוס ה-interrupt כבר נוקה, ולכן אם אינכם יכולים לסיים את העבודה בעצמכם, או שחזר את הסטטוס ב-Thread.currentThread().interrupt() כדי להשאיר את האות לקורא, או זרקו את החריגה כפי שהיא. בלוק catch ריק שאינו עושה דבר הוא סיבה קלאסית לבאגים שבהם shutdown אינו נכנס לתוקף או ש-shutdownNow מתעלמים ממנו.

אי אפשר לעצור thread ב-Thread.stop?

לא, אי אפשר. Thread.stop אינו בטוח ביסודו (הוא משחרר locks ומשאיר אותן במצב לא עקבי, וחושף אובייקטים שבורים ל-threads אחרים), ולכן הוא deprecated זה זמן רב, וקריאה אליו ב-Java הנוכחית זורקת UnsupportedOperationException. אותו דבר חל על Thread.suspend / resume. הדרך הלגיטימית היחידה לעצור thread היא עצירה שיתופית באמצעות interruption. אם משתמשים ב-ExecutorService, shutdown רק מפסיק לקבל משימות חדשות וממתין להשלמה — הוא אינו שולח interrupt למשימות רצות. מי שמנסה לעצור משימות רצות הוא shutdownNow, וזה best-effort (המימוש הסטנדרטי עובד דרך interruption).

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.