改善C#程序的建议8:避免锁定不恰当的同步对象

简介: 在C#中让线程同步的另一种编码方式就是使用线程锁。所谓线程锁,就是锁住一个资源,使得应用程序只能在此刻有一个线程访问该资源。可以用下面这句不是那么贴切的话来理解线程锁的作用:锁,就是让多线程变成单线程。

在C#中让线程同步的另一种编码方式就是使用线程锁。所谓线程锁,就是锁住一个资源,使得应用程序只能在此刻有一个线程访问该资源。可以用下面这句不是那么贴切的话来理解线程锁的作用:锁,就是让多线程变成单线程。在C#中,可以将被锁定的资源理解成new出来的普通对象。

既然需要锁定的资源就是一个C#中的对象,我们就该仔细思考,到底什么样的对象能够成为一个锁对象(也叫同步对象)?在选择同步对象的时候,应当始终注意以下几点:

    q同步对象在需要同步的多个线程中是可见的、同一个对象;

    q非静态方法中,静态变量不应作为同步对象;

    q值类型对象不能作为同步对象;

    q避免将字符串作为同步对象。

    q降低同步对象的可见性。

 

第一点,需要锁定的对象在多个线程中是可见的、同一个对象

“可见的”这是显而易见的,如果对象不可见,就不能被锁定。“同一个对象”,这理解起来也很好理解,如果锁定的不是同一个对象,那又如何来同步两个对象呢?可是,不见得我们在这上面不会犯错误。为了阐述本建议,我们先模拟一个必须使用到锁的场景:在遍历一个集合的过程中,同时在另外一个线程中删除集合中的某项。下面的这个例子中,如果没有lock语句,将会抛出异常InvalidOperationException:“集合已修改;可能无法执行枚举”:

public partial class FormMain : Form
{
public FormMain()
{
InitializeComponent();
}

AutoResetEvent autoSet
= new AutoResetEvent( false );
List
< string > tempList = new List < string > () { " init0 " , " init1 " , " init2 " };

private void buttonStartThreads_Click( object sender, EventArgs e)
{
object syncObj = new object ();

Thread t1
= new Thread(() =>
{
// 确保等待t2开始之后才运行下面的代码
autoSet.WaitOne();
lock (syncObj)
{
foreach (var item in tempList)
{
Thread.Sleep(
1000 );
}
}
});
t1.IsBackground
= true ;
t1.Start();

Thread t2
= new Thread(() =>
{
// 通知t1可以执行代码
autoSet.Set();
// 沉睡1秒是为了确保删除操作在t1的迭代过程中
Thread.Sleep( 1000 );
lock (syncObj)
{
tempList.RemoveAt(
1 );
}
});
t2.IsBackground
= true ;
t2.Start();
}
}

这是一个Winform窗体应用程序,我们需要演示的功能在按钮的点击事件中。对象syncObj对于线程t1和t2来说,在CLR中肯定是同一个对象。所以上面的示例运行没有问题。

现在,我们将以上示例重构一下。将实际的工作代码移到一个类型SampleClass中去,该示例要在多个SampleClass实例间操作一个静态字段:

private void buttonStartThreads_Click( object sender, EventArgs e)
{
SampleClass sample1
= new SampleClass();
SampleClass sample2
= new SampleClass();
sample1.StartT1();
sample2.StartT2();
}

class SampleClass
{
public static List < string > TempList = new List < string > () { " init0 " , " init1 " , " init2 " };
static AutoResetEvent autoSet = new AutoResetEvent( false );
object syncObj = new object ();

public void StartT1()
{
Thread t1
= new Thread(() =>
{
// 确保等待t2开始之后才运行下面的代码
autoSet.WaitOne();
lock (syncObj)
{
foreach (var item in TempList)
{
Thread.Sleep(
1000 );
}
}
});
t1.IsBackground
= true ;
t1.Start();
}

public void StartT2()
{
Thread t2
= new Thread(() =>
{
// 通知t1可以执行代码
autoSet.Set();
// 沉睡1秒是为了确保删除操作在t1的迭代过程中
Thread.Sleep( 1000 );
lock (syncObj)
{
TempList.RemoveAt(
1 );
}
});
t2.IsBackground
= true ;
t2.Start();
}
}

该示例运行起来抛出异常InvalidOperationException:“集合已修改;可能无法执行枚举”。查看类型SampleClass的方法StartT1和StartT2,方法内部锁定的是SampleClass的实例变量syncObject。实例变量意味着每创建一个SampleClass的实例都会生成一个syncObject对象。在本例中,调用者一共创建了两个SampleClass实例,继而分别调用:

sample1.StartT1();
sample2.StartT2();

以上代码锁定的是两个不同的syncObject,这等于完全没有达到两个线程锁定同一个对象的目的。要修正以上的错误,只要将syncObject变成static就可以了。

另外,思考一下lock(this),我们同样不建议在代码中编写这样的代码。如果两个对象的实例分别执行了锁定的代码,实际锁定的也是两个对象,完全不能达到同步的目的。

 

第二个注意事项:非静态方法中,静态变量不应作为同步对象

我们刚说完,要修正第一点中的示例,需要将syncObject变成static。这似乎和本注意事项有矛盾。实际上,第一点中的示例代码仅出于演示的目的。我们强烈建议你不要在实际应用中编写此类代码,在编写多线程代码时,要遵循这样的一个原则:类型的静态方法应当保证线程安全,非静态方法不需实现线程安全。FCL中的绝大部分类,都遵循了这个原则。如果将syncObject变成static,就相当于让非静态方法具备线程安全性,这带来的一个问题是,如果应用程序中该类型存在多个实例,在遇到这个锁的时候,都会产生同步,而这可能不是开发者原先所愿意看到的。

 

第三点:值类型对象不能作为同步对象

值类型在传递另一个线程的时候,会创建一个副本,这相当于每个线程锁定的也是两个对象。故,值类型对象不能作为同步对象。第二点实际也可以归结到第一点中。

 

第四点,锁定字符串是完全没有必要,而且相当危险的

这整个过程看上去和值类型正好相反。字符串在CLR中会被暂存到内存里,如果有两个变量被分配了相同内容的字符串,那么这两个引用会被指向同一块内存。所以,如果有两个地方同时使用了lock(“abc”),那么它们实际锁定的是同一个对象,导致整个应用程序被阻滞。

 

第五点:降低同步对象的可见性

可见范围最广的一种同步对象是typeof(SampleClass)。typeof方法所返回的结果,也就是类型的type,是SampleClass的所有实例所共有的,即:所有实例的type都指向typeof方法的结果。这样一来,如果我们lock(typeof(SampeClass)),当前应用程序中的所有SampleClass的实例的线程,将会全部被同步。这样编码是完全没有必要的,这样的同步对象太开放了。

另外,同步对象一般来说,也不应该是一个公共变量或属性。在FCL的早期版本中,一些常用的集合类型,如ArrayList,提供了公共属性SyncRoot,让我们锁定以便进行一些线程安全的操作。所以你一定会觉得我们刚才的结论不正确。其实不然,ArrayList的操作,大部分的应用场景不涉及到多线程同步,所以它的方法更多的是单线程应用场景。线程同步是一个非常耗时(也就是低效)的操作。若ArrayList的所有非静态方法都要考虑线程安全,那么ArrayList完全可以将这个SyncRoot变成静态私有。现在它将SyncRoot变为公开的,是让调用者自己去决定操作是否需要线程安全。在我们自己编写的大部分代码中,除非也有这样的要求,否则就应该始终考虑降低同步对象的可见性,将我们的同步对象藏起来,只开放给自己或自己的子类就够了(需要开放给子类的情况其实也不多见)。


之前内容:
改善C#程序的建议7:正确停止线程
改善C#程序的建议6:在线程同步中使用信号量
改善C#程序的建议5:引用类型赋值为null与加速垃圾回收
改善C#程序的建议4:C#中标准Dispose模式的实现
改善C#程序的建议3:在C#中选择正确的集合进行编码
改善C#程序的建议2:C#中dynamic的正确用法
改善C#程序的建议1:非用ICloneable不可的理由

Creative Commons License本文基于 Creative Commons Attribution 2.5 China Mainland License发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名 http://www.cnblogs.com/luminji(包含链接)。如您有任何疑问或者授权方面的协商,请给我留言。
目录
相关文章
|
1月前
|
算法
分布式锁设计问题之重建节点锁信息时要分为多个阶段如何解决
分布式锁设计问题之重建节点锁信息时要分为多个阶段如何解决
|
2月前
|
安全
线程操纵术并行策略问题之ForkJoinTask提交任务的问题如何解决
线程操纵术并行策略问题之ForkJoinTask提交任务的问题如何解决
|
2月前
|
人工智能
Sora信息问题之模拟对象状态变化存在的局限如何解决
Sora信息问题之模拟对象状态变化存在的局限如何解决
26 0
|
2月前
|
缓存
线程操纵术并行策略问题之工作窃取机制问题如何解决
线程操纵术并行策略问题之工作窃取机制问题如何解决
|
2月前
|
机器学习/深度学习 Java 数据挖掘
线程操纵术之更优雅的并行策略问题之并发和并行有区别问题如何解决
线程操纵术之更优雅的并行策略问题之并发和并行有区别问题如何解决
|
2月前
|
存储
代码优化设计问题之当方法体只有一行时,独立存在的方法的必要性开始存疑问题如何解决
代码优化设计问题之当方法体只有一行时,独立存在的方法的必要性开始存疑问题如何解决
|
3月前
|
Java 程序员
Java多线程编程是指在一个进程中创建并运行多个线程,每个线程执行不同的任务,并行地工作,以达到提高效率的目的
【6月更文挑战第18天】Java多线程提升效率,通过synchronized关键字、Lock接口和原子变量实现同步互斥。synchronized控制共享资源访问,基于对象内置锁。Lock接口提供更灵活的锁管理,需手动解锁。原子变量类(如AtomicInteger)支持无锁的原子操作,减少性能影响。
42 3
|
3月前
|
算法 Java 开发者
深入理解死锁的原因、表现形式以及解决方法,对于提高Java并发编程的效率和安全性具有重要意义
【6月更文挑战第10天】本文探讨了Java并发编程中的死锁问题,包括死锁的基本概念、产生原因和解决策略。死锁是因线程间争夺资源导致的互相等待现象,常由互斥、请求与保持、非剥夺和循环等待条件引起。常见死锁场景包括资源请求顺序不一致、循环等待等。解决死锁的方法包括避免嵌套锁、设置锁获取超时、规定锁顺序、检测与恢复死锁,以及使用高级并发工具。理解并防止死锁有助于提升Java并发编程的效率和系统稳定性。
271 0
|
4月前
|
监控 安全
线程死循环是多线程应用程序开发过程中一个难以忽视的问题,它源于线程在执行过程中因逻辑错误或不可预见的竞争状态而陷入永久运行的状态,严重影响系统的稳定性和资源利用率。那么,如何精准定位并妥善处理线程死循环现象,并在编码阶段就规避潜在风险呢?谈谈你的看法~
避免线程死循环的关键策略包括使用同步机制(如锁和信号量)、减少共享可变状态、设置超时、利用监控工具、定期代码审查和测试、异常处理及设计简洁线程逻辑。通过这些方法,可降低竞态条件、死锁风险,提升程序稳定性和可靠性。
74 0
|
4月前
|
存储 监控 并行计算
线程操纵术之更优雅的并行策略
本文详细介绍了并行编程以及一些并行问题案例中的真实业务场景。
112539 2