排他锁和共享锁有什么区别？
根据维基百科，
共享锁有时被称为“读取锁”，排他锁有时被称为“写入锁”。
你能否解释“共享”和“独占”这两个术语背后的推理？
我写下了这个答案，因为我认为这将是一个有趣的（合适的）类比：
在一个包含老师 （作家）和许多学生 （读者）的教室里，把可locking的对象想象成黑板 （可locking的）。
老师正在写一些东西（排他锁）在董事会上：
-
没有人可以阅读它，因为它仍然被写入，并且她阻止了你的视图=> 如果一个对象被独占locking，共享锁不能被获得 。
-
其他的老师也不会上来开始写作，或者董事会变得难以理解，并且让学生迷惑=> 如果一个对象被独占locking，则不能获得其他独占锁 。
当学生们正在阅读（共享锁）时，
-
他们都可以读取它上面的内容，一起=> 多个共享锁可以共存 。
-
教师等待他们完成阅读，然后再清除棋盘写入更多=> 如果一个或多个共享锁已经存在，则不能获得排他锁 。
这非常简单。 读取锁也被称为共享锁，因为多个进程可以同时读取。 读锁的要点是防止另一个进程获取写锁。 相比之下，写操作完成后写操作会禁止所有其他操作，这就是为什么它被描述为独占操作。
所以一个读锁说：“你现在可以读，但如果你想写，你将不得不等待”，而一个写锁说：“你将不得不等待”。
我意识到你正在研究支持你的学习，但是我无法抵制演讲的冲动。
无法使用locking是令人头疼的主要原因。 使用区分读写锁的locking系统是一个好的开始，但仔细的devise有时可以消除大部分的locking需求。 例如，会话状态不应该保存在每个状态元素的全局集合中。
我已经看到了这一点。 这是一个非常残酷的devise，对会话状态的每一次更改都会导致装箱和更改集合，从而导致长时间的写入locking。 开销被削弱，有效地将服务器降低到单线程行为。
将所有会话状态简单地聚合到一个结构中是一个巨大的改进。 会话状态的改变仅仅改变了会话状态结构成员的值。 由于没有其他会议有机会甚至有机会直接引用会话的状态，唯一被更新的集合是会话列表。 因此，locking是完全不必要的，只有在开始和结束时，吞吐量上升了3000倍。
另一种常见的lockingscheme是用户应用程序的线程之间共享的资源。 大多数现代框架使用消息而不是锁来解决这个问题。 当你“转换到UI线程”时，你实际上正在排队包含一个函数指针和一些参数（或一个委托和一个堆栈框架取决于实现）的消息。
-
独占或写入locking为写入文件指定部分的进程提供独占访问权限。 当写入locking到位时，其他进程不能locking文件的该部分。
-
共享或读取locking禁止任何其他进程请求在文件的指定部分写入locking。 但是，其他进程可以请求读取locking。
更多关于： http : //www.gnu.org/software/libc/manual/html_node/File-Locks.html
数据库端的原理也是一样的。 根据Oracle文档
独占locking模式可防止共享关联的资源。 这个locking模式是为了修改数据而获得的。 唯一locking资源的第一个事务是唯一可以改变资源的事务，直到独占锁被释放。
共享locking模式允许关联资源共享，具体取决于所涉及的操作。 多个读取数据的用户可以共享数据，持有共享锁以防止作者（需要独占locking）的并发访问。 几个交易可以
获取同一资源上的共享锁。
