理解lock锁的底层原理
(1)为什么要用锁?
对某个共享代码区域(临界区)进行串行访问,使用lock来保证串行的安全。
(2)lock的用法
代码语言:javascript复制lock (lockMe)
{
dict.Add(i.ToString(), DateTime.Now);
}
(3)lock的本质
通过ILSpy反编译查看可以知道,lock是个语法糖,编译后其实是Monitor.Enter 和 Monitor.Exit 的封装。
代码语言:javascript复制try
{
Monitor.Enter(lockMe, ref lockTake);
dict.Add(i.ToString(), DateTime.Now);
}
finally
{
if (lockTake)
{
Monitor.Exit(lockMe);
}
}
(4)lock为何需要引用类型?
首先,编译器要求lock中的所对象必须是引用类型。
其次,因为lock会用到对象头中的同步块索引来进行同步,值类型没有堆中的数据。
无锁化:线程的本地存储
(1)线程本地存储
static 的作用域在AppDomain下都可见,此时在多线程环境中,通过static共享变量的方式来同步,不可避免会出现锁竞争。如果能将作用域范围缩小,比如缩小到Thread级别,就可以避免锁竞争。例如:ConcurrentBag就是一个好的例子。
(2).NET中的解决方案
ThreadStatic(Attribute):当前线程拿到的是定义好的值,其他线程拿到的可能是默认值(值类型可能是0,引用类型可能是null,需要注意容错)。
ThreadLocal:与ThreadStatic最大的区别在于ThreadStatic只在第一个线程初始化,ThreadLocal则会为每个线程初始化。
(3)存储在哪里?
- PEB 进程环境块
- TEB 线程环境块
- TLS 线程本地存储(Thread Local Storage),取决于一共有多少个DataSlot
(4)应用场景
用来做数据库连接池:DB连接池 基于 ThreadLocal实现,每个线程只能看见自己的请求队列;
用来做链式追踪:比如Skywalking或Zipkin等,用到ThreadLocal做本地存储,记录完整的调用链条如:A -> B -> C -> D;
内核态锁知多少
(1)基于WaitHandle的内核锁
这种锁是基于Windows底层的内核数据结构来维护线程之间的同步,比如:
- AutoResetEvent / ManualResetEvent
- Semaphore
- Mutex
(2)优缺点
需要从用户态切换到内核态,相对来说比较重量级,相对耗费时间;内核模式的锁,不仅可用于创建线程同步,还可以创建进程同步。
用户态锁知多少
(1)用户态锁是啥?
例如下面的代码:
代码语言:javascript复制lock(obj)
{
... // todo [1ms]
}
大部分都是在临界区进行等待时间很短(比如1ms)的加锁,能不能让thread在CLR或C#层面内旋(自旋)一下,从而提高性能呢?使用用户态锁就可以避免上下文切换和内核切换带来的高开销。
(2)寻找解决方案
保持线程在用户态又要尽可能少的消耗CPU时间
时间片- Windows中一个时间片大概是30ms
- Thread.Sleep(0)
- 提前结束自己的时间片,然后把自己放入到就绪队列中,如果就绪队列中的线程优先级 >= Current Thread,那么其他线程会被调度
- 如果就绪队列中的线程优先级 < Current Thread,那么Current Thread只能继续执行【低优先级线程得不到执行】
- 整体CPU级别
- Thread.Yield()
- 提前结束自己的时间片,如果当前逻辑CPU上的就绪队列上有待执行的线程,那么这个线程就会被调度(不考虑优先级)【低优先级线程可以得到执行】
- 逻辑CPU级别
- 提前结束自己的时间片,然后把自己放入到就绪队列中,如果就绪队列中的线程优先级 >= Current Thread,那么其他线程会被调度
- 如果就绪队列中的线程优先级 < Current Thread,那么Current Thread只能继续执行【低优先级线程得不到执行】
- 整体CPU级别
- 提前结束自己的时间片,如果当前逻辑CPU上的就绪队列上有待执行的线程,那么这个线程就会被调度(不考虑优先级)【低优先级线程可以得到执行】
- 逻辑CPU级别
极端休眠时间- Sleep(1)
- 本质上和Sleep(1000)一样,都需要休眠
- 本质上和Sleep(1000)一样,都需要休眠
CAS原语- read, operate, write => 打包成原子性
借助CLR内的AwareLock::SpinWait()- C# SpinWait
- CLR SpinWait
(3).NET内置的SpinLock(用户态)
SpinLock在用法上和lock关键字差不多的。
代码语言:javascript复制class Program
{
public static SpinLock spinLock = new SpinLock();
public static int counter = 0;
static void Main(string[] args)
{
Parallel.For(1, 1000001, (i) =>
{
var lockTaken = false;
spinLock.Enter(ref lockTaken);
counter;
spinLock.Exit();
}
});
Console.WriteLine($"counter={counter}");
Console.ReadLine();
}
(4).NET CAS案例:Interlocked
CPU直接操作的,主要用在一些简单类型上:
- read
- operation
- write
class Program
{
public static SpinLock spinLock = new SpinLock();
public static int counter = 0;
static void Main(string[] args)
{
Parallel.For(1, 1000001, (i) =>
{
Interlocked.Increment(ref counter, 1);
});
Console.WriteLine($"counter={counter}");
Console.ReadLine();
}
混合态锁知多少
混合锁:用户态模式 内核态模式
(1)ManualResetEventSlim
它是如何实现的?
- lock
- ManualResetEvent
- CAS
- SpinWait(轻量级自旋锁)、SpinLock
(2)SemaphoreSlim
它是如何实现的?
- ManualResetEvent lock SpinWait
(3)ReaderWriterLockSlim
这个锁的内核版是 ReaderWriterLock,不带Slim就代表是内核态的锁。
这个锁顾名思义是读写锁,意思是:读可以并行,但写只能串行。EnterWriteLock() 需要等待所有的reader或writer锁结束,才能开始
(4)CountdownEvent
这个锁可以实现类似MapReduce的效果。
它是如何实现的?
基于ManualResetEvent事件做了底层封装。
线程安全集合知多少
(1)线程安全集合
.NET中都有哪些线程安全的集合类型?
ConcurrentBag 对应非线程安全类型:List
ConcurrentQueue 对应非线程安全类型:Queue
ConcurrentStack 对应非线程安全类型:Stack
ConcurrentDictionary 对应非线程安全类型:Dictionary
(2)BlockingCollection
BlockingCollection 意为 阻塞集合。
线程安全的集合 可以转换为 阻塞集合,只要它实现了IProducerConsumerCollection接口BlockingCollection可以实现类似发布订阅的业务场景应用:
- 生产端Add进去发布的消息
- 消费者端通过GetConsumingEnumerable()方法阻塞等待发布的消息
ConcurrentDictonary的两个大坑
(1)Values的坑
- 观察现象
- 业务场景:自己用ConcurrentDictionary封装了一个Cache
- FullGC 将 LOH 上的对象回收了
- 所有>=85000byte的都会被纳入LOH
- 观察源码
- Values方法每次都会生成一个新的List集合对象进行返回,每个对象都是大对象
- 如何改进
- 禁止调用Values方法
- 借助lock Dictionary实现类似操作避免每次生成新的List集合对象
(2)GetOrAdd的坑
- 观察现象
- 业务场景:自己用ConcurrentDictionary封装了一个Redis连接池缓存
- 借助GetOrAdd实现的CreateInstance方法未能实现线程安全导致连接池被大量反复创建
- 观察源码
- GetOrAdd方法中的valueFactory不是线程安全的
- 如何改进
- 借助Lazy改造字典的Value对象,保证创建方法只被执行一次,比如:将RedisConnection改为Lazy
共享变量在Release模式下的Bug
(1)现象
同样的代码,通过共享变量控制工作线程是否要结束自己,在Debug模式下没有问题,但是在Release模式下有问题。
(2)原因
JIT提供了错误的决策导致CPU在解析代码时做了优化,将 共享变量 存放在了CPU的寄存器中。
(3)WinDbg探究
- Release模式
- 查看memory中的共享变量的值
- CPU寄存器
- 查看共享变量的值
(4)解决方案
- 使用CancellationToken做取消
- 不用Cache,都读内存address中的对象,性能会相对较低
- 将共享变量 改为 易变结构,比如:private bool _shouldStop 改为 private volatile bool _shouldStop
小结
本篇,我们复习了锁机制相关的知识点。下一篇,我们将复习一下常见的.NET多线程相关的性能优化实践。
作者:周旭龙
出处:https://edisonchou.cnblogs.com
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接。