Có an toàn không khi dựa vào phân tích tĩnh đối với các lỗi đồng thời của Google sao chép lại một cách đáng tin cậy?

Tôi đã thừa hưởng một số mã Java mà tôi nghi ngờ có một số lỗi đồng thời khi đồng bộ hóa giữa một luồng truy vấn dữ liệu và một sự kiện IO cập nhật cùng một dữ liệu. Tôi đang thử nghiệm một công cụ phân tích tĩnh có tên ThreadSafe thực sự phát hiện các vấn đề tương tranh khác nhau (tức là trường được truy cập từ phương thức được gọi không đồng bộ mà không đồng bộ hóa và đồng bộ hóa truy cập không nhất quán vào bộ sưu tập).

Sau khi phát hiện ra việc tạo ra các cuộc đua dữ liệu khó khăn như thế nào bằng cách viết các bài kiểm tra đơn vị, tôi tự hỏi liệu có nên phụ thuộc vào ThreadSafe để "tái tạo" các lỗi một cách đáng tin cậy không? Điều tôi đang hỏi là, có an toàn không khi phụ thuộc vào công cụ phân tích tĩnh để cho tôi biết khi tôi sửa lỗi? (Tất nhiên, để sửa lỗi tôi sẽ cần hiểu từng lỗi trong ngữ cảnh).

Trả lời câu hỏi đầu tiên của bạn:

http://www.contemplateltd.com/threadsafe/faq#non-checkers

"Những loại khiếm khuyết đồng thời mà ThreadSafe không tìm kiếm?

• Chúng tôi chưa bao gồm hỗ trợ cho tất cả java.util.conc hiện. Cụ thể, ThreadSafe không kiểm tra việc sử dụng sai các tiện ích đồng bộ hóa nâng cao được cung cấp bởi java.util.concản, ví dụ như gói java.util.concản.atomic. Hiện tại nó cũng không bao gồm bất kỳ trình kiểm tra nào cho các lỗi có thể xảy ra khi viết các chương trình song song bằng cách sử dụng khung Fork-Join.

• Tìm lỗi trong các thuật toán không khóa phức tạp đòi hỏi công nghệ phân tích không có quy mô tốt. Các thuật toán như vậy nên để lại cho các chuyên gia đồng thời chuyên ngành. ThreadSafe có thể được cấu hình để tìm lỗi trong các ứng dụng sử dụng các thư viện chứa các thuật toán đó.

• Những phân tích mà chúng tôi đưa vào trong các bản phát hành mới của ThreadSafe được quyết định bởi cả những gì có thể sử dụng công nghệ phân tích đủ trưởng thành để tích hợp vào một sản phẩm có thể sử dụng và bởi các tính năng và khiếm khuyết đồng thời mà chúng ta thường thấy trong các chương trình Java 'trung bình'.

• Nếu bạn gặp vấn đề tương tranh Java hiện chưa được xử lý bởi ThreadSafe, các chuyên gia đồng thời Java của Contemplate có thể giúp đỡ bằng cách thêm cấu hình tùy chỉnh vào ThreadSafe và / hoặc sử dụng công nghệ phân tích nâng cao chưa đủ chín muồi để tích hợp vào ThreadSafe. "

Theo kinh nghiệm của tôi, một nhà phát triển xác định, có ý nghĩa, nhưng không biết gì có thể bao bọc đủ sự xáo trộn xung quanh một lỗi đồng thời mà công cụ phân tích sẽ bỏ lỡ.

Nếu công cụ cho rằng có lỗi, giả sử nó đúng cho đến khi bạn chứng minh khác. Đó là giá trị của công cụ. Nếu công cụ không tìm thấy bất kỳ lỗi nào, cách tốt nhất của bạn là giả vờ công cụ không tồn tại.

Nếu bạn muốn mã đồng thời đáng tin cậy (bằng bất kỳ ngôn ngữ nào), mục tiêu của bạn nên bao gồm:

1. Các phần quan trọng nên nhỏ và đơn giản để chúng không đáng để hiểu.
2. Các phần quan trọng nên được cách ly hoàn toàn với mã khác ở cấp nguồn.
3. Một hàm / phương thức / chương trình con liên quan đến mã đồng thời chỉ nên làm một việc . Nếu nó thao túng một nguyên thủy đồng bộ hóa (khóa, semaphore, v.v.) thì nó KHÔNG nên sử dụng bất kỳ tài nguyên được chia sẻ nào và nó KHÔNG được chứa các vòng lặp hoặc mã có điều kiện. Di chuyển "công việc thực tế" sang một chức năng riêng biệt. Điều này hỗ trợ mục 1.
4. Nếu bạn có bất kỳ loại khóa nào, nhà phát triển sẽ có thể đọc mã và xác định chính xác (các) tài nguyên mà khóa đó bảo vệ trong 30 giây hoặc ít hơn. Nếu điều đó không rõ ràng với bạn, điều đó sẽ không rõ ràng với chàng trai tiếp theo. Và nó có thể không rõ ràng với những người đã viết mã. Vì vậy, nó có thể bị hỏng.
5. Khả năng hiển thị của tài nguyên bạn đang bảo vệ không được lớn hơn khả năng hiển thị của nguyên thủy đồng bộ hóa bảo vệ tài nguyên đó. Không phải thành phần nào cũng có thể nhìn thấy đối với phần mã lớn hơn.
6. V.v. Phần còn lại của danh sách thực sự chỉ là một loạt các cách để nghỉ ngơi các mục 1 và 2.

Nếu mã của bạn được thiết kế và tổ chức đúng, bạn sẽ có thể nhìn vào một phần rất nhỏ của mã để hiểu và tin tưởng vào sự tương tranh. Khi bạn đạt được mục tiêu đó , sau đó cung cấp mã cho công cụ phân tích tĩnh và xem liệu nó có đồng ý không.

Và đưa mã cho một vài nhà phát triển không phải là guru khác để xem xét. Yêu cầu họ giải thích cách hoạt động của đồng thời và tại sao nó đúng. Nếu họ không thể giải thích nó, nó vẫn quá phức tạp.

Sản xuất một công cụ phân tích tĩnh hữu ích liên quan đến việc cân bằng một số mối quan tâm xung đột, bao gồm ít nhất là sau đây:

• Tỷ lệ dương tính giả (báo động sai)
• Tỷ lệ âm tính (lỗi chưa phát hiện)
• Thời gian chạy và khả năng mở rộng

Dương tính giả là một mối quan tâm quan trọng với các công cụ phát hiện lỗi vì chúng lãng phí thời gian của nhà phát triển. Có thể loại bỏ âm tính giả, nhưng đối với nhiều loại lỗi, bao gồm cả lỗi đồng thời, điều này sẽ liên quan đến sự gia tăng không thể chấp nhận được trong tỷ lệ dương tính giả. Tỷ lệ của cả dương tính giả và âm tính giả có thể được giảm với chi phí tăng thời gian chạy, nhưng các kỹ thuật phân tích chính xác nhất không vượt quá các ứng dụng nhỏ, và dù sao cả hai đều không thể giảm xuống bằng không.

Các công cụ phân tích động thường yêu cầu tỷ lệ dương tính giả là 0%, nhưng đó là vì họ chỉ tìm thấy lỗi một khi chúng thực sự xảy ra. Đối với một điều kiện cuộc đua hoặc bế tắc chỉ xảy ra một lần trong một mặt trăng xanh, điều đó không hữu ích lắm.

Vì những lý do này, ThreadSafe không hứa sẽ tìm thấy tất cả các lỗi đồng thời - nó nhằm mục đích tìm ra những lỗi quan trọng nhất, với tỷ lệ dương tính giả thấp. Một số người dùng đã thử dùng ThreadSafe trên mã với một lỗi đồng thời đã biết mà họ mất nhiều ngày để tìm và phát hiện ra rằng nó tìm thấy lỗi đó - và thường là các lỗi chính hãng khác mà họ không biết - không có lỗi tích cực trong vài phút.

Một nơi tốt để bắt đầu thông tin về ThreadSafe là bài viết InfoQ này . Để biết thêm, hãy xem trang web ThreadSafe nơi bạn có thể đăng ký dùng thử miễn phí.

(Tiết lộ: ThreadSafe là một công cụ thương mại và tôi là người đồng sáng lập của Contemplate, công ty sản xuất nó.)