多进程共享内存续篇-大锁
读写锁，就是多人可以同时访问，但是同时只有一个人可以修改的规则。
由于锁本身的申请和释放，对于性能有很大的消耗，那么一般写只发生在特殊情况，也就是很少发生。
读锁常在就是性能的优化方案，只有在申请写锁的时候，才会释放读锁。
和之前有什么不一样呢，例如，连续的在不同地方的100次读，以前是要100次读锁的申请和释放，现在只有初始的一次申请读锁，中间完全没有别的消耗。
代码如何实现呢？
过程如下：
当有一个进程需要写，那么就要等所有的进程的读锁释放，所以在申请和释放读锁的地方，申请的动作还在。
首先，需要一个共享变量，当一个进程申请写锁，所有进程可以知晓。
然后，以前申请和释放读锁的地方，实际不是申请和释放，而是对于写进程的共享变量的判断。
所谓的判断，如果有进程申请写进程，那么所有进程都会根据共享变量，手动释放一次读锁，然后申请一次读锁。
由于写申请在前，那么在手动释放读锁后，写锁获得权限，申请读锁就要等写锁的释放。
总结：一个进程内的变量read_flag=0，进程开始时候申请读锁，只会申请一次，变量置1。后面再申请和释放，对多进程的共享变量write_flag判断
【多进程共享内存续篇-大锁】write_flag=0：无进程申请写锁
申请读锁函数，read_flag==1，进来直接退出；read_flag==0，初次申请；
释放读锁函数，直接return，不用对变量进行判断。
write_flag=1：有进程申请写锁
申请读锁函数，手动申请一次读锁，然后手动释放一次读锁；
释放读锁函数，手动申请一次读锁，然后手动释放一次读锁。
写锁很简单，只需要将共享变量置位，然后去申请写锁就OK了。
注意这里对共享变量的操作，是在没有获得写锁的时候，修改共享变量，如何保证唯一性？
其实不需要唯一性：
其他进程同时申请写锁，那么修改变量都是一个目的，把它置1；
修改的同时，有读锁操作，可能会当时没有读到或读错？那么下次再读呗，只是多了一次读的时间；
推荐阅读
- 放屁有这三个特征的，请注意啦！这说明你的身体毒素太多
- 爱就是希望你好好活着
- 昨夜小楼听风
- 知识
- 死结。
- 我从来不做坏事
- 烦恼和幸福
- 关于QueryWrapper|关于QueryWrapper,实现MybatisPlus多表关联查询方式
- Linux下面如何查看tomcat已经使用多少线程
- 说得清，说不清