问独占锁和共享锁有什么区别？

EN

我写下这个答案是因为我认为这将是一个有趣(也合适)的类比：

把一个可锁的物体想象成教室里的黑板(可锁的)，里面有一位老师(作家)和许多学生(读者)。

当老师在黑板上写一些东西(独家锁)时：

1. 没有人能读到它，因为它还在编写中，如果一个对象被独占锁定，共享锁就无法获得，她就会阻塞您的视图=>。
2. 其他教师也不会出现并开始写作，或者板变得不可读，如果一个对象被独占锁定，无法获得其他独占锁，就会混淆学生的=>。

当学生正在阅读(共享锁)板上的内容时：

1. 它们都可以读取上面的内容，=>多个共享锁可以共存。
2. 如果一个或多个共享锁已经存在，则教师在清除板以编写更多=>之前等待他们完成阅读，无法获得独占锁。

很简单。读锁也称为共享锁，因为多个进程可以同时读取。读锁的目的是防止另一个进程获取写锁。相反，在写操作完成时，写锁会抑制所有其他操作，这就是为什么它被描述为排他的原因。

所以读锁写着“你现在可以读，但是如果你想写，你就得等”，而写锁说“你必须等”。

我意识到你的研究是为了支持你的学习，但我无法抗拒演讲的冲动。

不称职地使用锁定是性能问题的主要原因。使用区分读锁和写锁的锁定系统是一个很好的开始，但是仔细的设计有时可以消除锁定的大部分需要。例如，会话状态不应在每个状态元素的一个全局集合中保存。

我确实看到过这件事。这是一个非常糟糕的设计，会导致装箱，并且对会话状态的每一次更改都会改变集合，这会导致持久的写锁。管理费用严重受损，有效地将服务器减少为单线程行为。

简单地将所有会话状态聚合到一个结构中是一个巨大的改进。对会话状态的更改仅仅改变了会话状态结构的成员的值。由于没有其他会话有机会或甚至没有机会直接引用会话的状态，因此更新的唯一集合是会话列表。因此，锁定是完全没有必要的，只有在开始和结束时，并且吞吐量增加了3000倍。

另一个常见的锁定场景是用户应用程序的线程之间共享资源。大多数现代框架使用消息而不是锁来解决这个问题；当您“转换到UI线程”时，实际上是在排队排队，其中包含一个函数指针和一些参数(或委托和堆栈框架，具体取决于实现)。

• 独占锁或写锁提供进程独占访问权限，用于写入文件的指定部分。当写锁就位时，没有其他进程可以锁定文件的这一部分。
• 共享或读取锁禁止任何其他进程对文件的指定部分请求写锁。但是，其他进程可以请求读取锁。

更多信息：node/File-Locks.html