Fix lỗi macOS "Application Not Responding — Force Quit?" (Beach Ball)

TL;DR

Bạn thấy bánh xe xoay (SPOD), macOS hiện hộp thoại "Application Not Responding — Force Quit?", và bạn cần ứng dụng hoạt động trở lại NGAY. Mở Activity Monitor, sắp xếp theo CPU hoặc Memory, tắt tiến trình gây ra vấn đề, rồi khởi động lại ứng dụng. Các phần bên dưới giải thích chính xác lý do tại sao điều này xảy ra — và cách ngăn nó tái diễn.

# Force-quit từ Terminal (nhanh nhất khi Dock bị đơ)
kill -9 $(pgrep -x "AppName")

# Hoặc dùng killall
killall -9 "Slack"

Nguyên nhân thực sự gây ra bánh xe xoay

Bánh xe xoay (SPOD — Spinning Pinwheel of Death) xuất hiện khi luồng chính của ứng dụng không phản hồi trong khoảng 4–5 giây. macOS phát hiện sự im lặng này và hiển thị hộp thoại Application Not Responding — Force Quit?.

Các nguyên nhân thường gặp:

Tiến trình chiếm 100% CPU — một tiến trình nền, plugin, hoặc chính ứng dụng bị kẹt trong vòng lặp vô tận
Áp lực bộ nhớ — RAM đầy, macOS đang hoán đổi liên tục, và luồng chính bị chặn khi chờ xử lý lỗi trang bộ nhớ
Tắc nghẽn I/O ổ đĩa — HDD chậm, SSD sắp hỏng, hoặc ổ mạng SMB/NFS bị mất kết nối mà ứng dụng vẫn cố truy cập
Deadlock bên trong ứng dụng — hai luồng chờ nhau; không gì được thực thi
File preferences hoặc cache bị lỗi — ứng dụng cố phân tích một plist hỏng khi khởi động và đơ luôn

Bước 1 — Xác định nguyên nhân gốc rễ trước

Đừng chỉ force-quit rồi bỏ qua. Hãy tìm hiểu tại sao — nếu không, tối nay nó sẽ xảy ra lại.

# Kiểm tra các tiến trình ăn CPU nhiều nhất hiện tại
top -o cpu -n 20 -l 1 | head -30

# Kiểm tra áp lực bộ nhớ
vm_stat | grep -E "Pages (free|active|inactive|speculative|wired|occupied)"

# Kiểm tra I/O ổ đĩa (cần sudo)
sudo fs_usage -w -f filesys 2>&1 | grep -i "your_app_name"

Activity Monitor (Applications → Utilities → Activity Monitor) thường nhanh hơn để quan sát trực quan:

Tab CPU → sắp xếp theo % CPU giảm dần — tìm tiến trình nào vượt 90%
Tab Memory → kiểm tra biểu đồ "Memory Pressure" ở dưới cùng (màu đỏ là đang có vấn đề)
Tab Disk → tìm tiến trình nào có "Bytes Read" tăng đột biến lên hàng trăm MB

Bước 2 — Force quit đúng cách

Cách A: Hộp thoại Force Quit (CMD+OPT+ESC)

Nhấn ⌘ + ⌥ + Esc, chọn ứng dụng được đánh dấu (Not Responding), nhấn Force Quit. Hoạt động trong hầu hết các trường hợp — chỉ là đừng mong dữ liệu chưa lưu sẽ còn.

Cách B: Dùng lệnh kill trong Terminal (khi giao diện bị đơ hoàn toàn)

# Lấy PID
pgrep -lx "Slack"

# Thử gửi SIGTERM nhẹ nhàng trước
kill $(pgrep -x "Slack")

# Nếu sau 5 giây vẫn còn sống, kết liễu nó
sleep 5 && kill -9 $(pgrep -x "Slack") 2>/dev/null

Cách C: Kill từ Activity Monitor

Chọn tiến trình → nhấn nút X trên thanh công cụ → "Force Quit". Kết quả giống Cách A, chỉ là đi theo đường khác.

Bước 3 — Khắc phục nguyên nhân gốc rễ

Trường hợp: Áp lực bộ nhớ cao / đang hoán đổi

# Xem dung lượng swap đang dùng
sysctl vm.swapusage

# Giải phóng các trang bộ nhớ không hoạt động mà không ảnh hưởng ứng dụng đang chạy
sudo purge

Swap dùng liên tục trên 2 GB là dấu hiệu đáng lo. Hãy đóng bớt ứng dụng nền hoặc chấp nhận rằng bạn cần thêm RAM. Để kiểm tra rò rỉ bộ nhớ trong một ứng dụng cụ thể:

leaks --atExit -- /Applications/AppName.app/Contents/MacOS/AppName

Trường hợp: File preferences bị lỗi

Một file .plist hỏng có thể làm ứng dụng đơ ngay trong vài giây sau khi khởi động, lặp đi lặp lại. Hãy sao lưu, xóa nó, và để ứng dụng tự tạo lại từ đầu.

# Sao lưu và xóa file preferences của ứng dụng
cd ~/Library/Preferences
mv com.company.AppName.plist com.company.AppName.plist.bak

# Xóa cache preferences để macOS không dùng phiên bản cũ
killall cfprefsd

Khởi động lại ứng dụng. Nếu hoạt động bình thường, plist cũ chính là thủ phạm — hãy xóa file .bak đi.

Trường hợp: Cache ứng dụng bị lỗi

# Xóa cache của ứng dụng
rm -rf ~/Library/Caches/com.company.AppName

# Các ứng dụng Electron (VSCode, Slack, Notion) cũng cache tại đây:
rm -rf ~/Library/Application\ Support/AppName/Cache
rm -rf ~/Library/Application\ Support/AppName/Code\ Cache

Trường hợp: Ổ mạng bị mất kết nối gây tắc nghẽn I/O

Một ứng dụng đọc file từ ổ SMB hoặc NFS sẽ bị treo vô thời hạn ngay khi ổ đó mất kết nối. Luồng chính chỉ ngồi đó chờ phản hồi từ hệ thống file mà không bao giờ đến.

# Liệt kê các ổ mạng đang được mount
mount | grep -E "smb|nfs|afp"

# Unmount cưỡng bức ổ mạng bị treo
diskutil unmount force /Volumes/MyShare
# hoặc
sudo umount -f /Volumes/MyShare

Trường hợp: Tiến trình helper bị lỗi (rất phổ biến với ứng dụng Electron)

# Tìm tất cả tiến trình con được tạo bởi ứng dụng
pstree -p $(pgrep -x "Slack") 2>/dev/null || pgrep -P $(pgrep -x "Slack")

# Kill tiến trình helper, không phải ứng dụng chính
kill -9

Trường hợp: Spotlight đang lập chỉ mục thư mục dữ liệu của ứng dụng

Các tiến trình mds/mdworker của Spotlight có thể gây ra I/O ổ đĩa cực lớn khi quyết định lập chỉ mục lại thư mục dữ liệu của ứng dụng — thường xảy ra ngay sau khi cập nhật.

# Xác nhận mds đang chiếm CPU
top -o cpu | grep mds

# Tạm dừng lập chỉ mục
sudo mdutil -a -i off
# Bật lại sau vài phút
sudo mdutil -a -i on

Để loại trừ vĩnh viễn: System Settings → Siri & Spotlight → Spotlight Privacy → kéo thư mục vào.

Bước 4 — Thu thập dữ liệu chẩn đoán trước khi kill

Nếu ứng dụng bị đơ thường xuyên, cần điều tra đúng cách. Hãy lấy spindump trước khi force-quit — nó ghi lại toàn bộ stack trace của mỗi luồng tại thời điểm đơ, đây chính xác là thứ bạn cần để báo cáo lỗi có giá trị.

# Lấy spindump của ứng dụng đang đơ (lưu vào /tmp/)
sudo spindump AppName -o /tmp/AppName_spindump.txt

# Hoặc sample tiến trình trong 10 giây
sample $(pgrep -x "AppName") 10 -file /tmp/AppName_sample.txt

Mở file và tìm các stack frame lặp lại. Sự lặp lại đó chính là deadlock hoặc vòng lặp nóng của bạn.

Kiểm tra kết quả

Sau khi áp dụng bản sửa lỗi, theo dõi ứng dụng trong 60 giây trước khi kết luận đã xong:

# Theo dõi CPU và bộ nhớ theo thời gian thực
top -o cpu -s 2 -l 30 | grep -i "appname"

# Theo dõi áp lực bộ nhớ — làm mới mỗi 5 giây
vm_stat 5

Biểu đồ Memory Pressure trong Activity Monitor nên giữ màu xanh lá. Màu vàng là cảnh báo. Màu đỏ có nghĩa là ứng dụng sẽ tiếp tục đơ cho đến khi bạn đóng bớt ứng dụng hoặc bổ sung RAM — không có bản vá nào giữ được trong trạng thái đó.

Khi mọi cách đều thất bại — giải pháp triệt để

Toàn bộ giao diện macOS bị đơ? Chuột di chuyển được nhưng không gì phản hồi? SSH vào từ máy khác và khởi động lại phiên làm việc:

# Kill window server — phiên làm việc hiện tại sẽ kết thúc ngay lập tức
ssh user@your-mac
sudo killall -KILL loginwindow

Bạn sẽ bị đăng xuất và phiên làm việc khởi động lại sạch sẽ. Dữ liệu chưa lưu sẽ mất, nhưng cách này nhanh hơn nhiều so với tắt nguồn cứng và tránh được nguy cơ hỏng hệ thống file.

Ngăn chặn tái diễn

Luôn giữ ít nhất 10–15% dung lượng ổ đĩa trống — macOS dùng SSD làm bộ nhớ hoán đổi ảo; ổ gần đầy đồng nghĩa với swap chậm, dẫn đến bánh xe xoay
Chạy sudo periodic daily weekly monthly thỉnh thoảng để dọn dẹp các cache hệ thống tích tụ theo thời gian
Cập nhật ứng dụng — một số lượng đáng ngạc nhiên các lỗi ANR đã được vá trong phiên bản mới nhất và hầu hết người dùng không biết vì họ không bao giờ cập nhật
Với các ứng dụng Electron (VSCode, Slack, Notion), kiểm tra ghi chú phát hành của phiên bản hiện tại; rò rỉ bộ nhớ trong Electron rất phổ biến và thường được vá trong 1–2 bản cập nhật
Chỉ bị bánh xe xoay khi dùng pin? System Settings → Battery → Low Power Mode làm giảm hiệu năng CPU đáng kể. Hãy tắt tính năng này trong các phiên làm việc nặng.