FixedThreadPool vs CachedThreadPool: ความชั่วร้ายน้อยกว่าสองอย่าง

ฉันมีโปรแกรมที่สร้างเธรด (~ 5-150) ซึ่งทำงานได้หลายอย่าง ในขั้นต้นฉันใช้ a FixedThreadPoolเพราะคำถามที่คล้ายกันนี้แนะนำว่าเหมาะสำหรับงานที่มีชีวิตอยู่นานกว่าและด้วยความรู้ที่ จำกัด มากเกี่ยวกับมัลติเธรดฉันจึงคิดว่าอายุการใช้งานเฉลี่ยของเธรด (หลายนาที) " มีอายุยืนยาว "

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

ลองใช้ทั้งคู่ในเบื้องต้นดูเหมือนจะไม่มีความแตกต่างดังนั้นฉันจึงมีแนวโน้มที่จะไปด้วยวิธีCachedThreadPoolเดียวที่จะหลีกเลี่ยงของเสีย อย่างไรก็ตามช่วงชีวิตของเธรดหมายความว่าฉันควรเลือกFixedThreadPoolและจัดการกับเธรดที่ไม่ได้ใช้แทนหรือไม่? คำถามนี้ทำให้ดูเหมือนว่าเธรดพิเศษเหล่านั้นจะไม่สูญเปล่า แต่ฉันขอขอบคุณสำหรับคำชี้แจง

CachedThreadPool เป็นสิ่งที่คุณควรใช้สำหรับสถานการณ์ของคุณเนื่องจากไม่มีผลเสียใด ๆ ในการใช้เธรดที่รันเป็นเวลานาน ข้อคิดเห็นในเอกสาร java เกี่ยวกับ CachedThreadPools เหมาะสำหรับงานสั้น ๆ เพียงแนะนำว่าเหมาะสมเป็นพิเศษสำหรับกรณีดังกล่าวไม่ใช่ว่าไม่สามารถหรือไม่ควรใช้สำหรับงานที่เกี่ยวข้องกับงานที่รันเป็นเวลานาน

หากต้องการอธิบายเพิ่มเติมExecutors.newCachedThreadPoolและExecutors.newFixedThreadPoolทั้งสองได้รับการสนับสนุนโดยการใช้เธรดพูลเดียวกัน (อย่างน้อยใน JDK แบบเปิด) เพียงแค่มีพารามิเตอร์ที่แตกต่างกัน ความแตกต่างเพียงแค่เธรดต่ำสุดสูงสุดเวลาฆ่าเธรดและประเภทคิว

public static ExecutorService newFixedThreadPool(int nThreads) {
     return new ThreadPoolExecutor(nThreads, nThreads,
                                   0L, TimeUnit.MILLISECONDS,
                                   new LinkedBlockingQueue<Runnable>());
 }

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                 60L, TimeUnit.SECONDS,
                                 new SynchronousQueue<Runnable>());
}

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

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

ทั้งสองอย่างFixedThreadPoolและCachedThreadPoolเป็นความชั่วร้ายในแอพพลิเคชั่นที่โหลดสูง

CachedThreadPool เป็นอันตรายมากกว่า FixedThreadPool

หากแอปพลิเคชันของคุณโหลดสูงและต้องการเวลาแฝงต่ำควรกำจัดทั้งสองตัวเลือกเนื่องจากข้อเสียด้านล่าง

1. ลักษณะของคิวงานที่ไม่ถูกผูกไว้: อาจทำให้หน่วยความจำไม่เพียงพอหรือมีเวลาแฝงสูง
2. เธรดที่รันเป็นเวลานานจะทำให้CachedThreadPoolควบคุมการสร้างเธรดไม่ได้

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

1. ตั้งค่าคิวงานเป็นคิวที่มีขอบเขตเพื่อให้สามารถควบคุมได้ดีขึ้น
2. มี RejectionHandler ที่ถูกต้อง - ตัวจัดการ RejectionHandler หรือ Default ของคุณเองที่จัดทำโดย JDK
3. หากคุณมีสิ่งที่ต้องทำก่อน / หลังเสร็จสิ้นภารกิจให้ลบล้างbeforeExecute(Thread, Runnable)และafterExecute(Runnable, Throwable)
4. แทนที่ThreadFactoryหากจำเป็นต้องปรับแต่งเธรด
5. ควบคุมขนาดพูลเธรดแบบไดนามิกในเวลารัน (คำถาม SE ที่เกี่ยวข้อง: Dynamic Thread Pool )

ดังนั้นฉันจึงมีโปรแกรมที่สร้างเธรด (~ 5-150) ซึ่งทำงานได้หลายอย่าง

คุณแน่ใจหรือไม่ว่าคุณเข้าใจวิธีการประมวลผลเธรดโดยระบบปฏิบัติการและฮาร์ดแวร์ที่คุณเลือก? Java แมปเธรดกับเธรด OS อย่างไรแมปเธรดกับเธรด CPU ฯลฯ อย่างไร ฉันถามเพราะการสร้าง 150 เธรดภายใน ONE JRE เหมาะสมก็ต่อเมื่อคุณมีคอร์ / เธรด CPU ขนาดใหญ่อยู่ข้างใต้ซึ่งส่วนใหญ่ไม่เป็นเช่นนั้น ขึ้นอยู่กับ OS และ RAM ที่ใช้การสร้างมากกว่า n เธรดอาจส่งผลให้ JRE ของคุณถูกยกเลิกเนื่องจากข้อผิดพลาด OOM ดังนั้นคุณควรแยกความแตกต่างระหว่างเธรดและงานที่ต้องทำโดยเธรดเหล่านั้นจำนวนงานที่คุณสามารถประมวลผลได้ ฯลฯ

และนั่นคือปัญหาของ CachedThreadPool: มันไม่สมเหตุสมผลที่จะจัดคิวงานที่รันเป็นเวลานานในเธรดซึ่งไม่สามารถรันได้จริงเนื่องจากคุณมีแกน CPU เพียง 2 คอร์เท่านั้นที่สามารถประมวลผลเธรดเหล่านั้นได้ หากคุณลงท้ายด้วย 150 เธรดที่กำหนดเวลาไว้คุณอาจสร้างค่าใช้จ่ายที่ไม่จำเป็นจำนวนมากสำหรับตัวกำหนดตารางเวลาที่ใช้ภายใน Java และระบบปฏิบัติการเพื่อประมวลผลพร้อมกัน สิ่งนี้เป็นไปไม่ได้เลยหากคุณมีแกน CPU เพียง 2 คอร์เว้นแต่เธรดของคุณกำลังรอ I / O หรือเช่นนั้นตลอดเวลา แต่ในกรณีนั้นเธรดจำนวนมากจะสร้าง I / O จำนวนมาก ...

และปัญหานั้นจะไม่เกิดขึ้นกับ FixedThreadPool ที่สร้างขึ้นด้วยเธรดเช่น 2 + n โดยที่ n มีค่าต่ำพอสมควรเนื่องจากทรัพยากรฮาร์ดแวร์และระบบปฏิบัติการนั้นใช้โดยมีค่าใช้จ่ายน้อยกว่ามากสำหรับการจัดการเธรดซึ่งไม่สามารถทำงานได้