lý do đằng sau khóa bên trong khóa?

Question

Tôi đang xem xét một mã ví dụ trong một cuốn sách và đi qua đoạn mã sau (đơn giản hóa). Trong mã, khi Subscribe(T subscriber) được gọi, luồng đi vào phần khóa. và sau đó, khi mã bên trong khóa gọi phương thức AddToSubscribers(T subscriber), phương thức có khóa khác. tại sao khóa thứ hai này lại cần thiết?

public abstract class SubscriptionManager<T> where T : class 
{ 
    private static List<T> subscribers; 
    private static void AddToSubscribers(T subscriber) 
    { 
     lock (typeof(SubscriptionManager<T>)) 
     { 
     if (subscribers.Contains(subscriber)) 
      return; 
     subscribers.Add(subscriber); 
     } 
    } 

    public void Subscribe(T subscriber) 
    { 
     lock (typeof(SubscriptionManager<T>)) 
     { 
     AddToSubscribers(subscriber); 
     } 
    } 
} 

Answer 1

Trong ngữ cảnh đó, không phải; tuy nhiên, kể từ khi khóa được tái tham gia có thể hữu ích để đảm bảo rằng bất kỳ người gọi khác của AddToSubscribers quan sát khóa. Trên thực tế, vì lý do đó tôi muốn nói "xóa nó khỏi Subscribe và chỉ để AddToSubscribers thực hiện khóa".

Tuy nhiên! Khóa trên Type khá nguy hiểm. Một trường sẽ an toàn hơn:

// assuming static is correct 
private static readonly object syncLock = new object(); 

và lock(syncLock). Tùy thuộc vào thời điểm subscribers được chỉ định, bạn cũng có thể nhận được ngay với lock(subscribers) (và không có trường bổ sung).

Tôi cũng nên lưu ý rằng có phương thức dụ thêm vào trạng thái tĩnh là khá .... bất thường; IMO Subscribe phải là phương pháp static, vì nó không liên quan gì đến phiên bản hiện tại.

Answer 2

Trong mã bạn đã đăng, không cần thiết. Nhưng sau đó một lần nữa, mã bạn đăng không đầy đủ - ví dụ danh sách người đăng ký không bao giờ được khởi tạo.

Khóa trên typeof (SubscriptionManager) có lẽ không phải là một ý kiến ​​hay - khóa trên trường subscribers sẽ tốt hơn - nhưng sẽ yêu cầu trường đăng ký được khởi tạo, ví dụ:

private static List<T> subscribers = new List<T>(); 

Answer 3

Có thể bạn nên đọc gần mẫu đó và xem sách nói về điều gì.

Đối với trường hợp cụ thể đó - không, khóa thứ hai là không cần thiết.

Lưu ý: Mẫu nguy hiểm vì nó khóa trên vật thể công cộng (loại). Thông thường một ổ khóa trên đối tượng riêng tư đặc biệt để mã bên ngoài không thể nhầm lẫn giới thiệu deadlocks bằng cách nhầm lẫn khóa trên cùng một đối tượng.

Answer 4

Tôi cũng phải đối mặt với tình huống khi đã sử dụng Khóa lồng nhau.

Trường hợp của tôi là, chức năng của khóa thứ hai có thể được gọi từ nơi khác, vì đó là chức năng tĩnh. Tuy nhiên, đối với trường hợp của bạn, nó sẽ không cần thiết vì mỗi thành viên dữ liệu thuộc về Instance và không tĩnh.