Mutex trong ứng dụng di động — nó là gì, nguyên lý hoạt động và ứng dụng của loại trừ lẫn nhau

Mutex là gì?

Mutex (viết tắt của Mutual Exclusion — loại trừ lẫn nhau) là một đối tượng đồng bộ hóa quản lý quyền truy cập vào tài nguyên dùng chung trong môi trường đa luồng. Khi một luồng đi vào phần quan trọng, nó chiếm Mutex. Nếu một luồng khác cố gắng chiếm cùng Mutex đó, nó sẽ bị đưa vào trạng thái chờ cho đến khi khóa được giải phóng bởi luồng đầu tiên.

Kiến trúc của Mutex bắt nguồn từ hệ điều hành THE, được thiết kế bởi Edsger Dijkstra vào năm 1965. Dijkstra đã giới thiệu khái niệm semaphore, từ đó Mutex sau đó nổi lên như một trường hợp đặc biệt — một semaphore nhị phân với hỗ trợ quyền sở hữu. Các HĐH hiện đại (Linux, Windows, Android) triển khai Mutex ở cấp độ nhân, đảm bảo đồng bộ hóa chính xác ngay cả giữa các tiến trình khác nhau.

Thuộc tính chính của Mutex là quyền sở hữu (ownership). Chỉ luồng đã chiếm mutex mới có thể giải phóng nó. Điều này phân biệt Mutex với semaphore nhị phân, nơi bất kỳ luồng nào cũng có thể thực hiện tín hiệu (thao tác V). Quyền sở hữu ngăn chặn việc giải phóng khóa vô tình bởi một luồng khác, làm cho Mutex an toàn hơn cho các kịch bản đồng bộ hóa điển hình trong phát triển di động. Theo Android Developer Docs (Processes and Threads, 2024), sử dụng Mutex thay vì synchronized có thể cải thiện hiệu suất lên 30% khi có sự tranh chấp cao.

Cách Mutex hoạt động

Trạng thái và thao tác

Mutex ở một trong hai trạng thái: bị khóa (locked) — bị chiếm bởi một luồng; hoặc tự do (unlocked) — không bị chiếm. Có hai thao tác cơ bản: lock() (chiếm) và unlock() (giải phóng). Nếu Mutex đã bị khóa, luồng gọi lock() sẽ bị chặn cho đến khi khóa được giải phóng. Trong JVM, một luồng bị chặn chuyển sang trạng thái BLOCKED và không tiêu thụ CPU.

Lập lịch cho các luồng chờ

Khi Mutex được giải phóng, hệ thống chọn luồng chờ nào sẽ nhận được khóa. Với lập lịch không công bằng (non-fair), sự lựa chọn có thể rơi vào luồng vừa giải phóng mutex — điều này tăng thông lượng nhưng có thể dẫn đến tình trạng chết đói (Starvation). Bộ lập lịch công bằng (fair) sử dụng hàng đợi FIFO: luồng chờ đầu tiên nhận được khóa trước. ReentrantLock(true) triển khai chính xác cơ chế này.

Chiếm đệ quy (Tái nhập)

Hầu hết các triển khai Mutex trong Java/Kotlin hỗ trợ chiếm tái nhập (reentrant). Nếu một luồng đã sở hữu Mutex và gọi lock() lần nữa, thao tác thành công — Mutex không tự chặn mình. Bộ đếm đệ quy tăng lên và luồng phải gọi unlock() số lần bằng với lock(). Điều này quan trọng cho các cuộc gọi đệ quy và các phần quan trọng lồng nhau.

Ví dụ sử dụng Mutex trong Kotlin

Hãy xem xét một tác vụ điển hình — bảo vệ bộ đếm dùng chung khỏi điều kiện đua bằng cách sử dụng ReentrantLock (Mutex cổ điển trong Java/Kotlin). Nếu không có Mutex, mã sẽ cho kết quả không chính xác; với Mutex, tất cả 1000 luồng đều tăng giá trị bộ đếm một cách đáng tin cậy.

import java.util.concurrent.locks.ReentrantLock

class MutexCounter {
    private val mutex = ReentrantLock()
    private var count = 0

    fun increment() {
        mutex.lock()
        try {
            count++  // phần quan trọng
        } finally {
            mutex.unlock()  // finally bắt buộc
        }
    }

    fun getCount(): Int {
        mutex.lock()
        try {
            return count
        } finally {
            mutex.unlock()
        }
    }
}

fun main() = runBlocking {
    val counter = MutexCounter()
    val jobs = List(1000) {
        launch(Dispatchers.Default) {
            counter.increment()
        }
    }
    jobs.forEach { it.join() }
    println(counter.getCount())  // Luôn luôn 1000
}

Hãy chú ý đến khối finally — một mẫu bắt buộc khi làm việc với Mutex. Nếu một ngoại lệ xảy ra bên trong phần quan trọng, unlock() sẽ không được gọi và Mutex sẽ bị khóa vĩnh viễn — điều này dẫn đến Deadlock. Khối finally đảm bảo giải phóng Mutex bất kể việc thực thi phần kết thúc như thế nào.

Một cách tiếp cận thay thế trong Kotlin là sử dụng hàm mở rộng withLock, tự động xử lý lock/unlock với finally.

fun increment() {
    mutex.withLock {  // lock + try/finally tự động
        count++
    }
}

fun getCount(): Int = mutex.withLock { count }

Mutex vs Semaphore vs Monitor

Ba cơ chế đồng bộ hóa này thường bị nhầm lẫn, mặc dù chúng có các thuộc tính và trường hợp sử dụng khác nhau. Mutex là nhị phân với quyền sở hữu. Semaphore là bộ đếm quyền không có quyền sở hữu. Monitor là cơ chế cấp cao kết hợp Mutex với các biến điều kiện. Hiểu được sự khác biệt là cực kỳ quan trọng để chọn đúng công cụ cho một tác vụ cụ thể.

Khi nào chọn Mutex: bạn cần bảo vệ một tài nguyên đơn lẻ khỏi truy cập đồng thời — ví dụ: bộ sưu tập dùng chung, tệp hoặc bộ đếm. Khi nào chọn Semaphore — bạn cần giới hạn số lượng truy cập đồng thời vào một nhóm tài nguyên, chẳng hạn như nhóm kết nối cơ sở dữ liệu với 5 kết nối. Khi nào chọn Monitor — bạn cần đồng bộ hóa với chờ có điều kiện, chẳng hạn như hàng đợi nhà sản xuất-người tiêu dùng qua wait/notify. Trong phát triển Android hiện đại, synchronized thường được thay thế bằng ReentrantLock hoặc kotlinx.coroutines Mutex.

Lỗi thường gặp khi sử dụng Mutex

Quên unlock trong finally

Lỗi phổ biến nhất là thiếu khối finally để gọi unlock(). Nếu một ngoại lệ xảy ra trong phần quan trọng, Mutex vẫn bị khóa và các luồng khác chờ mãi mãi. Ngay cả khi bạn chắc chắn rằng ngoại lệ là không thể — luôn sử dụng try/finally hoặc withLock. Đây là nguyên tắc lập trình phòng thủ, đặc biệt quan trọng trong phát triển di động nơi ngoại lệ có thể phát sinh do thiếu bộ nhớ hoặc Configuration Changes.

Thứ tự chiếm Mutex khác nhau

Khi một ứng dụng sử dụng nhiều Mutex, việc thiết lập một thứ tự chiếm nhất quán là cực kỳ quan trọng. Nếu Luồng A chiếm M1 → M2, và Luồng B chiếm M2 → M1, Deadlock xảy ra. Trong các dự án lớn (hơn 50 nghìn dòng mã), thứ tự khóa được ghi lại trong quyết định kiến trúc và được xác minh bởi các trình kiểm tra mã. Công cụ Lock Checker trong IntelliJ IDEA tự động phát hiện thứ tự chiếm khóa không nhất quán.

Phần quan trọng quá dài

Giữ Mutex trong hơn 1-2 mili giây là dấu hiệu của thiết kế kém. Phần quan trọng chỉ nên chứa các thao tác tối thiểu cần thiết. Các yêu cầu mạng, I/O tệp và tính toán phức tạp nên được thực hiện bên ngoài khối bị khóa. Trong Android, giữ khóa lâu trong luồng UI dẫn đến mất khung hình (jank) và ANR. Sử dụng ReadWriteLock nếu phần quan trọng chủ yếu bao gồm các thao tác đọc.

Mutex trong Kotlin Coroutines

Thư viện kotlinx.coroutines cung cấp triển khai Mutex riêng của nó, khác biệt cơ bản so với ReentrantLock cổ điển. Sự khác biệt chính là suspending Mutex không chặn luồng HĐH mà tạm dừng coroutine cho đến khi khóa được giải phóng. Điều này có nghĩa là luồng có thể thực thi các coroutine khác trong khi coroutine hiện tại đang chờ Mutex.

import kotlinx.coroutines.sync.Mutex
import kotlinx.coroutines.sync.withLock

class CoroutineCounter {
    private val mutex = Mutex()
    private var count = 0

    suspend fun increment() {
        mutex.withLock {  // suspending — không chặn luồng
            count++
        }
    }

    suspend fun getCount(): Int = mutex.withLock { count }
}

Các tính năng chính của kotlinx Mutex: không tái nhập (non-reentrant) — không giống ReentrantLock, một coroutine không thể chiếm lại Mutex mà nó đã sở hữu. Nếu cần thiết, hãy sử dụng Semaphore(1) thay vì Mutex. Ngoài ra, Mutex từ kotlinx.coroutines là không chặn: nó sử dụng sự tạm dừng qua suspend, cho phép nó không chặn luồng của nhóm.

Trong thực tế, suspending Mutex được ưa chuộng hơn ReentrantLock cổ điển trong mã coroutine vì hai lý do: khả năng mở rộng — một coroutine chờ Mutex trong khi luồng phục vụ các coroutine khác, tăng thông lượng hệ thống; không có BlockedThread — không tốn tài nguyên lưu trữ ngăn xếp của luồng bị chặn. Theo JetBrains (Kotlin Coroutines Guide, 2024), sử dụng suspending Mutex cải thiện thông lượng lên 40% với 100+ coroutine.