Ngừng lỗi rò rỉ bộ nhớ của Monosnap — chuyển đổi trong 60 giây

Lỗi rò rỉ không phải do máy tính của bạn

Nếu bạn đang tự hỏi liệu có phải do máy của mình — một driver cũ, những điều kỳ lạ của Windows 11, một tab Chrome chạy quá mức — thì không phải vậy. Lỗi rò rỉ nằm bên trong Monosnap và đã tồn tại trong nhiều năm. Tìm kiếm r/monosnap và bạn sẽ tìm thấy hết chủ đề này đến chủ đề khác mô tả cùng một vấn đề.

Đây là những gì xảy ra bên trong. Mỗi khi Monosnap chụp một vùng, nó sẽ cấp phát một bộ đệm khung (frame buffer) đủ lớn để chứa dữ liệu pixel thô. Đối với màn hình 2560 x 1440, đó là khoảng 14 MB. Khi trình chỉnh sửa đóng lại, các bộ đệm đó lẽ ra phải được trả về cho hệ điều hành. Trong Monosnap, chúng thường không được trả về — chúng bị giữ lại bởi heap của trình kết xuất Electron, chờ đợi một lượt thu gom rác (garbage-collection) mà hoặc không bao giờ chạy hoặc chạy quá muộn. Trong một ngày làm việc với hơn 40 lần chụp, các bộ đệm bị giữ lại tích tụ thành hàng trăm megabyte RAM ảo.

Giải pháp là một ứng dụng khác

Kiến trúc của Monosnap gắn liền lỗi rò rỉ với chính Electron, và việc vá lỗi sẽ yêu cầu viết lại toàn bộ quy trình chụp. Việc viết lại đó đã không xảy ra trong năm năm. Giải pháp thực tế là một công cụ được thiết kế mà không gặp phải vấn đề này ngay từ đầu.

Maxisnap được xây dựng trên PyQt6 và được biên dịch bằng PyInstaller thành một tệp thực thi Win32 duy nhất. Không có tiến trình Chromium. Mỗi lần chụp sẽ cấp phát một QImage, trình chỉnh sửa tham chiếu đến nó, và khi cửa sổ đóng lại, tham chiếu sẽ bị loại bỏ và bộ nhớ ngay lập tức được trả về cho hệ điều hành — bởi vì mô hình sở hữu của PyQt và cơ chế đếm tham chiếu của Python đều giải phóng bộ nhớ ngay lập tức thay vì chờ đợi một GC thế hệ.

Theo thực nghiệm: Maxisnap ở trạng thái chờ khi khởi chạy là khoảng 50 MB. Sau 72 giờ chạy liên tục với các lần chụp thường xuyên, nó vẫn ở khoảng 50 MB. Biểu đồ trên được lấy từ nhật ký thực tế.