Starvation ในแอปพลิเคชันมือถือ — สาระสำคัญ สาเหตุ และวิธีป้องกันภาวะขาดแคลนเธรด

Starvation คืออะไร?

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

ในการพัฒนาแอปมือถือ Starvation แสดงออกเป็น การทำงานของงานที่ไม่เท่าเทียมกัน: บางงานทำงานทันที ในขณะที่บางงานประสบกับความล่าช้าอย่างรุนแรง ตัวอย่างเช่น เธรดซิงโครไนซ์ข้อมูลพื้นหลังอาจไม่สามารถเข้าถึงฐานข้อมูลได้เลยหากเธรด UI และตัวจัดการแอนิเมชันแซงหน้ามันตลอดเวลา ตาม Android Developer Blog (Performance Matters, 2023) ประมาณ 12% ของเฟรมที่พลาด (jank) บน Android เกิดจาก Starvation ของงานพื้นหลังที่การเรนเดอร์ต้องพึ่งพา

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

สาเหตุของภาวะขาดแคลนเธรด

ล็อคที่ไม่เป็นธรรม (Non-Fair Locks)

synchronized ใน Java และ Kotlin เป็นตัวอย่างคลาสสิกของกลไกที่ไม่เป็นธรรม ภายใต้การแข่งขันสูง JVM อาจให้ล็อคแก่เธรดที่ทำงานอยู่เดียวกันอย่างต่อเนื่อง ในขณะที่เธรดอื่นแพ้การแข่งขันตลอดเวลา นี่ไม่ใช่บั๊กของ JVM แต่เป็นข้อแลกเปลี่ยนในการออกแบบ: ล็อคที่ไม่เป็นธรรมให้ปริมาณงานที่สูงกว่าโดยแลกกับความเป็นธรรมในการเข้าถึง สำหรับแอปพลิเคชันมือถือที่มี 4–8 เธรด ปัญหานี้มีความเกี่ยวข้องเป็นพิเศษ

การใช้ลำดับความสำคัญที่ไม่ถูกต้อง

การตั้งค่า ลำดับความสำคัญของเธรดที่แตกต่างกัน อาจนำไปสู่ Starvation ของเธรดที่มีลำดับความสำคัญต่ำ ใน Android Runtime ตัวจัดลำดับ CFS (Completely Fair Scheduler) ของ Linux จัดสรรเวลา CPU ตามสัดส่วนของลำดับความสำคัญ และหากเธรดที่มีลำดับความสำคัญสูงทำงานตลอดเวลา เธรดที่มีลำดับความสำคัญต่ำอาจไม่ได้รับเวลา CPU เลย Google ไม่แนะนำอย่างยิ่งให้เปลี่ยนลำดับความสำคัญของเธรดใน Android — ระบบจัดการเอง

ส่วนวิกฤตที่ยาวนาน

หากเธรดล็อค นานเกินไป (ดำเนินการคำนวณหนัก คำขอเครือข่าย หรือการดำเนินการไฟล์ภายในบล็อก synchronized) เธรดอื่นที่รอล็อคนั้นจะขาดแคลน นี่เป็นอันตรายโดยเฉพาะใน Android ซึ่งการดำเนินการยาวนานบนเธรด UI ทำให้เกิด ANR และการย้ายไปยังเธรดพื้นหลังโดยไม่ปรับส่วนวิกฤตให้เหมาะสมเพียงแค่ย้ายปัญหา Starvation ไปยังเธรดผู้ทำงาน

ตัวอย่าง Starvation ในโค้ด Kotlin

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

class SharedResource {
    private val lock = Any()

    fun criticalSection(id: String) {
        synchronized(lock) {
            println("$id ได้รับการเข้าถึง")
            Thread.sleep(10)  // จำลองการทำงาน
        }
    }
}

fun main() {
    val resource = SharedResource()

    // เธรดที่มีลำดับความสำคัญสูง — ทำงานตลอดเวลา
    val highPriority = Thread {
        while (true) {
            resource.criticalSection("High")
        }
    }

    // เธรดที่มีลำดับความสำคัญต่ำ — อาจไม่ได้รับการเข้าถึงเลย
    val lowPriority = Thread {
        while (true) {
            resource.criticalSection("Low")
        }
    }

    highPriority.start()
    lowPriority.start()
    // "Low" อาจไม่พิมพ์ข้อความเลย — Starvation!
}

ในตัวอย่างนี้ เธรด highPriority ล็อคตลอดเวลาและปล่อยเพียง 10 ms เนื่องจากลักษณะที่ไม่เป็นธรรมของ synchronized ตัวจัดลำดับ JVM มีแนวโน้มสูงที่จะให้ล็อคอีกครั้งกับเธรดเดียวกับที่เพิ่งปล่อย — เธรดที่มีลำดับความสำคัญต่ำขาดแคลน วิธีแก้คือใช้ ReentrantLock(true) พร้อมแฟล็ก fair ซึ่งรับประกันลำดับการรอ FIFO

เวอร์ชันที่แก้ไขด้วยล็อคที่เป็นธรรมช่วยให้การเข้าถึงทรัพยากรเป็นธรรม

class FairSharedResource {
    private val fairLock = ReentrantLock(true)  // fair = true

    fun criticalSection(id: String) {
        fairLock.lock()
        try {
            println("$id ได้รับการเข้าถึง (fair)")
            Thread.sleep(10)
        } finally {
            fairLock.unlock()
        }
    }
}

Starvation vs Deadlock vs Livelock

ปัญหาหลายเธรดคลาสสิกสามอย่าง — Starvation, Deadlock และ Livelock — มักถูกจัดกลุ่มร่วมกัน แต่กลไกและวิธีแก้ต่างกัน Starvation — เธรดพร้อมแต่ไม่สามารถรับทรัพยากรได้ Deadlock — เธรดถูกบล็อกโดยการรอแบบวน Livelock — เธรดทำงานอยู่แต่ไม่คืบหน้า

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

วิธีตรวจจับ Starvation

Thread Dump ที่ถ่ายซ้ำๆ ในช่วงเวลาสั้นๆ — วิธีการพื้นฐานในการตรวจจับภาวะขาดแคลน หากเธรดอยู่ในสถานะ RUNNABLE อย่างต่อเนื่องแต่สแต็กการเรียกไม่เปลี่ยนแปลงในหลายๆ ดัมพ์ — นี่คือสัญญาณคลาสสิกของ Starvation ใน Android Studio ใช้ Android Profiler ด้วยการบันทึกสถานะเธรดตามเวลา

การตรวจจับอัตโนมัติเป็นไปได้ผ่าน การตรวจสอบเวลาในการทำงาน ของงาน หากงานที่มีเวลาในการทำงานที่คาดเดาได้ (เช่น 50 ms) ใช้เวลา 5 วินาทีขึ้นไป — มีความเป็นไปได้สูงที่จะเกิด Starvation ในแอปพลิเคชันมือถือ Firebase Performance Monitoring ช่วยให้คุณตั้งค่า trace ที่กำหนดเองสำหรับส่วนวิกฤตและรับการแจ้งเตือนเมื่อเกินเกณฑ์

ในการวินิจฉัย Starvation ที่เกิดจากบล็อก synchronized ให้ใช้ Java Flight Recorder (JFR) (ใช้ได้บน Android ผ่าน OpenJDK API) หรือ Async Profiler เครื่องมือเหล่านี้แสดงว่ามอนิเตอร์ใดมีเวลารอนานที่สุดและเธรดใดแข่งขันกันเพื่อแต่ละมอนิเตอร์ ข้อมูล JFR รวมเข้ากับ IntelliJ IDEA Ultimate ผ่านโปรไฟล์เลอร์ในตัว

วิธีป้องกันภาวะขาดแคลนเธรด

Fair Lock (ReentrantLock พร้อมแฟล็ก true)

ReentrantLock(true) รับประกันว่าเธรดได้รับล็อคตามลำดับ FIFO ต่างจาก synchronized ตรงที่ล็อคที่เป็นธรรมไม่อนุญาตให้เธรดที่เพิ่งปล่อยล็อคล็อคซ้ำทันที สิ่งนี้กำจัด Starvation อย่างสมบูรณ์ แม้ว่าจะลดปริมาณงานโดยรวม 10–20% เนื่องจากค่าใช้จ่ายในการดูแลคิว

โครงสร้างอะตอมมิกแบบไม่มีล็อค

โครงสร้างข้อมูลแบบไม่มีล็อค (ConcurrentHashMap, AtomicReference, LongAdder) กำจัด Starvation โดยนิยาม เพราะไม่มีล็อคที่เธรดเดียวสามารถถือครองได้ การดำเนินการทั้งหมดใช้คำสั่ง CAS ของ CPU ซึ่งรับประกันว่าเธรดอย่างน้อยหนึ่งเธรดจะคืบหน้าในจำนวนขั้นตอนที่จำกัด สำหรับการพัฒนาแอปมือถือ ให้เลือกใช้ ConcurrentLinkedQueue สำหรับคิวงาน

ส่วนวิกฤตที่สั้น

การลดเวลาในการถือล็อค เป็นวิธีสากลในการลดความเสี่ยงของ Starvation ย้ายการดำเนินการหนัก (เครือข่าย I/O ดิสก์ การคำนวณซับซ้อน) ออกจากบล็อก synchronized ใช้ ReadWriteLock สำหรับสถานการณ์ที่ผู้อ่านไม่ควรขาดแคลนเนื่องจากผู้เขียนที่หายาก ไลบรารี Kotlin Coroutines มี Mutex พร้อมกลไกการระงับที่ไม่บล็อกเธรด OS

ตัวแปรเงื่อนไขและสัญญาณ

Condition.await() และ signal() ควรใช้ด้วยความระมัดระวัง: เธรดที่รอใน Condition ตื่นขึ้นพร้อมกับเธรดอื่น (spurious wakeup) และทั้งหมดแข่งขันกันเพื่อล็อค หากเธรดกลับไปรอทันทีหลังจาก await ในขณะที่เธรดอื่นได้รับล็อค เธรดที่ขาดแคลนอาจตื่นและหลับไปอย่างไม่สิ้นสุด ตรวจสอบเงื่อนไขในลูป while เสมอ แทนที่จะใช้ if เพื่อให้แน่ใจว่ามีการตรวจสอบซ้ำ