iUcool的博客

面对没有获取锁的现场，通常有两种处理方式。本文主要讲述自旋锁自旋锁其实是一种很乐观的锁，他认为只要再等一下下锁便能释放，避免了操作系统进程调度和线程切换。

sync.Pool是内置对象池技术，可用于缓存临时对象，避免因频繁建立临时对象所带来的消耗以及对GC造成的压力在很多知名框架中都可以看到sync.Pool的大量使用。比如Gin中用sync.Pool来复用每个请求都会创建的对象但是值得注意的是sync.Pool缓存的对象可能被无通知的清理。

VLL锁管理结构由储存到每个原始数据的的未完成锁写请求数量CX和未完成锁读请求数量CS中心事务请求全局队列TxnQueue组成。

sudog代表在等待队列中的goroutine，比如channel发送接受。由于goroutine和同步对象的关系是多对多，因此需要sudog映射。

sync.Cond采用一个L锁进行保护条件变量，并使用通知队列来堵塞和通知goroutine。

而其他需要用到的场景，可以通过参数控制是否加锁、或者将递归调用函数提取到新函数中交予新函数加锁、或者采用channel之类的来迂回达成可重入锁的目的。那么在实际开发工程中就可能存在虽然是同一个goroutine运行，但是在一个方法内很难知道其他方法是否也用了这个锁，用来做什么。那么重入锁在此时便无法保证保护不变量。比如说存在两个接口方法A、B，A中调用了B，但是由于这两个方法都可能被其他方法所调用，所以如果没有可重入锁便可能会死锁。在工程中使用锁的原因在于为了保护不变量，也可以用于保护内、外部的不变量。

考虑到redis主从同步集群中，如果从master获取到锁之后，就故障换成了从节点，那么就会导致锁失效，因此提出了RedLock的分布式锁算法。该算法依赖于这样的假设:虽然进程之间没有同步时钟，但每个进程中的本地时间几乎以相同的速率更新，与锁的自动释放时间相比，误差很小。在上述锁中，存在一个问题——如果A获取了锁，但是由于执行时间过长，导致B也获取到过期后的锁，此时并会同时存在多方获取锁。以下是删除特定value的锁的lua脚本，这样就可以防止删除不属于自己的锁。在锁竞争比较激烈情况下，性能损耗较大。

单线程模式简单，没有多线程、进程通信、竞争问题，但是也无法发挥多核CPU性能，并且在线程意外终止或者进入死循环的情况下容易导致整个故障。若非建立连接请求，直接交由sub reactor将连接加入到连接队列进行监听，并创建handler处理。若是建立连接请求事件，则由acceptor接受请求，然后创建handler处理具体业务处理。若是建立连接请求事件，则由acceptor接受请求，然后创建handler处理具体业务处理。若是建立连接请求事件，则由acceptor进行连接。

H2O生成是只有同时存在且仅存在的情况下两个氢原子和一个氧原子，才能生成下一个氢原子或者氧原子，如此循环往复。

Mutex是Golang常见的并发原语，不仅在开发过程中经常使用到，如channel这种具有golang特色的并发结构也依托于Mutex从而实现Mutex有正常饥饿模式。正常模式：等待者会入队，但一个唤醒的等待者不能持有锁，以及与新到来的goroutine进行竞争。新来的goroutine有一个优势——他们已经运行在CPU上。超过1ms没有获取到锁，就会进入饥饿模式。

因为关闭channel的时候会唤醒所有等待的发送goroutine，并继续执行堵塞之后的逻辑，发现goroutine是被关闭后唤醒的就会panic。将锁分散在对象图中听起来像一场噩梦，但若是channel则是被期望，被鼓励的。从上面结构可以看出，channel是一个拥有锁的双向队列，储存了数据、缓冲、等待接收发送队列等。为什么在发送关闭的channel会panic，而接收关闭的channel则会接收到零值呢？我认为这句话很有意思，并发是我们代码能保证的，可是并行的事情得交给机器来处理。

管程是允许线程具有互斥、等待（堵塞）某个条件为false的能力的同步结构。具有通知其他线程他们特定条件已经满足的机制。管程为线程提供了可以暂时放弃独占访问，以便在重新获得独占访问并恢复任务之前等待满足某些条件。管程有互斥锁以及特定条件变量组成。条件变量本质上是等待特定条件的线程的容器互斥：同一时刻只允许一个线程访问共享资源同步：线程之间通信、协作。

哲学家就餐是很经典的并发问题，问题描述如下五位哲学家在同一张桌子旁吃饭。每个哲学家在餐桌上都有自己的位置。每个盘子之间都有一把叉子。这道菜是一种意大利面，必须用两把叉子吃。每个哲学家只能思考或者吃。此外，哲学家只有在有左右叉子的时候才能吃意大利面。因此，只有当离他们最近的两个邻居在思考而不是吃饭时，他们才会有两把叉子。哲学家吃完饭后，会把叉子都放下。问题是如何设计一种方案(一种并行算法)，使哲学家不会挨饿;

信号量是一个变量或者抽象数据类型，被用于控制在并发系统临界区问题多个线程对公共资源的访问。与自旋锁、栅栏一起作为同步手段。一个普通的信号量是单纯取决于程序员定义条件而改变的变量允许任意资源计数的信号量称为计数信号量，而限制为0和1(或锁定/解锁，不可用/可用)值的信号量称为二进制信号量，用于实现锁。我们可以将信号量看作记录特定资源的数量记录，并耦合调整该记录的安全操作。数量记录，即意味着信号量并不记录哪些资源可以操作使用信号量时，有很多行为需要注意。

errgroup为goroutine组提供了通知、错误传递、上下文取消功能。一般在一组goroutine出现错误需要取消全部goroutine的情况使用到。

sync.Map相当于goroutine并发安全的Map。sync.Map针对两种常见情况进行了优化sync.Map在第一次使用后不能被复制过程展现最开始写入数据只会到dirty中，因为dirty主要接受写数据。此时read amended为true读取时从read读取，此时read并没有数据，misses记录从read读取失败的次数，当misses大于等于dirty数据量时，将dirty升级为read。升级也就是对dirty进行地址拷贝并且dirty清空，misses置为0。

生产者消费者是极其经典的并发同步模型，描述了在共享固定大小缓冲区下，生产者生产一定量数据放入缓冲区，而消费者则从缓冲区消费取出一定量数据。生产者消费者问题还有一个名字是有限缓冲问题。生产者消费者更加强调了两边写读线程的角色，而有限缓冲则将目光聚焦到中间的缓冲semaphore 实现semaphore（信号量）是一个变量或者抽象数据类型，被用于控制在并发系统临界区问题多个线程对公共资源的访问。与自旋锁、栅栏一起作为同步手段。一个普通的信号量是单纯取决于程序员定义条件而改变的变量。可以将信号量看作

Java线程之间通信一般而言，线程都有自己私有的线程上下文。但是当我们需要多个线程进行相互协作的时候，进行线程之间的通信就十分重要了。锁与同步线程同步可以认为是线程之间按照一定的顺序执行，为了达到线程同步，我们可以通过锁来实现。等待/通知机制Java多线程的等待通知是基于Object类的wait()以及notify()，notifyAll()方法来是实现的notify()会随机唤醒一个正在等待的线程，而notifyAll()会唤醒所有正在等待的线程。假设线程A持有了一个锁lock，使用了l