go乐观锁和悲观锁和分段锁

最新推荐文章于 2023-08-31 11:39:30 发布

zhu0902150102

最新推荐文章于 2023-08-31 11:39:30 发布

阅读量738

点赞数

分类专栏：后端文章标签： golang

本文链接：https://blog.csdn.net/zhu0902150102/article/details/112392173

版权

后端专栏收录该内容

15 篇文章 0 订阅

订阅专栏

1.为啥要使用锁？

防止多个用户同时对数据的并发操作时会带来以下数据不一致的问题

2.概念

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。（实现:在sql语句后面加上for update）

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。(实现：在表上加version)

3.乐观锁的实现机制

（1）version(也叫数据版本)

数据每次更新都在原版本的基础上递增，如果更新的时候发现版本号不一致，则认为数据是老数据，重新获取数据并处理

type DataBlock struct {
	Id                 string      `json:"id" bson:"id"`
	Version            string      `json:"version"       bson:"version"`	
}



func (this *dataBlockRepository) Update(dBlock *DataBlock, oldVersion string) (code int, err error) {
	id, _ := primitive.ObjectIDFromHex(dBlock.Id)
	condition := bson.M{"_id": id, "version": oldVersion}
	var data map[string]interface{}
	err = utility.DecodeByJson(dBlock, &data)
	updateContent := bson.M{"$set": data}
	result, err := this.mongoClient.UpdateWithResult(collection, condition, updateContent)

	if result.ModifiedCount <= 0 {
		return response.RESPONSE_FOR_SYNCHRONOUS_UPDATE, nil
	}
	return response.SUCCESS, nil
}

更新的时候用老版本作为匹配条件更新，如果修改记录为0也就是匹配不上，则可认为被更新过，重新获取数据并处理

（2）CAS:全称ComparedAndSwap

实现原理就是：更新之前先判断内存对象的值是否是获取的时候相同，如果相同，则认为没有更新过，更新，如果不同，则认为更新了，重新获取数据并计算

go ComparedAndSwap汇编代码：

底层也是通过加锁来实现的，只不过是通过硬件（cpu）来完成锁操作以避免频繁的上下文切换

TEXT runtime∕internal∕atomic·Cas64(SB), NOSPLIT, $0-25
	MOVQ	ptr+0(FP), BX
	MOVQ	old+8(FP), AX
	MOVQ	new+16(FP), CX
	LOCK
	CMPXCHGQ	CX, 0(BX)
	SETEQ	ret+24(FP)
	RET

借用了CPU提供的原子性指令来实现。CAS操作修改共享变量时候不需要对共享变量加锁，而是通过类似乐观锁的方式进行检查，本质还是不断的占用CPU 资源换取加锁带来的开销（比如上下文切换开销）

从硬件层面来实现原子操作，有两种方式：

1、总线加锁：因为CPU和其他硬件的通信都是通过总线控制的，所以可以通过在总线加LOCK#锁的方式实现原子操作，但这样会阻塞其他硬件对CPU的访问，开销比较大。

2、缓存锁定：频繁使用的内存会被处理器放进高速缓存中，那么原子操作就可以直接在处理器的高速缓存中进行而不需要使用总线锁，主要依靠缓存一致性来保证其原子性。

java JUC cas的实现：和go的实现几乎是一样的，其中自旋那一部分也叫自旋锁，在某种程度上说，如果冲突比较多，那么自旋的for循环也会消耗一部分性能，可能导致性能还不如悲观锁

@HotSpotIntrinsicCandidate
public final int getAndAddInt(Object o, long offset, int delta) {
	// v是要返回的旧值
    int v;
    // do while自旋，乐观锁。直到CAS成功
    do {
        v = getIntVolatile(o, offset);
        // CAS操作，一次没成功就继续尝试，直到set成功
    } while (!weakCompareAndSetInt(o, offset, v, v + delta));
    return v;
}