如何防止TThreadList死锁

[jingzu]

我在多线程中的多个类中使用TThreadList，发现很容易发生死锁，如果防止死锁？

[Waiting4you]

LockList后不要忘记UnlockList

不要嵌套LockList/UnlockList对(这个要小心,比如你的基类里每个方法都用了Lock对, 继承后Lock了又调用基类的方法,或者相互调用都有可以嵌套)

[jingzu]

是不能嵌套LockList/UnlockList对吗？

[jingzu]

我每个类中都说明了一个自己的私有TThreadLis，会相互影响吗？

[chenxidu]

以前老师告诉我，少使用不必要的指针

[kangji]

嵌套可以，但是你的思路不要乱

私有的不会相互影响

[Waiting4you]

我说的嵌套LockList/UnlockList对当然是指同一个TThreadList实例啦

[zwh202342]

私有的不会相互影响

[huzhangyou]

防止死锁要考虑的问题很多
使用TCriticalSection要释放

[ghostkissangel]

sleep（毫秒） 一下，交给主程序一段时间

[痞子酷]

try
{
LockList
...
}
__finally
{
UnlockList
}

[FFSB]

gz

[EagleFew]

TThreadList 其实就是 TList + 临界段
可以这样使用 :

TThreadList *hlstThread = new TThreadList();
TList *lst = NULL;

lst = hlstThread->LockList(); // 在这里进入临界段
// 使用lst 操作完成后
hlstThread->UnlockList(); // 在这里退出临界段

他们必须配对使用否则,就会发生死锁

[僵哥]

try
{
LockList
...
}
__finally
{
UnlockList
}
===============================
很奇怪，我看到有很多人都喜欢这种写法，但是我很反对，万一LockList失败，那么也会执行到UnlockList，则这个执行就不是必要的，如果是多次嵌套，则中间有一次，出现如此错误，就会导致不必要的解锁，而导致访问冲突，或者说达不到Lock的效果。这只是其中一种情况。
另一种是创建一个对象然后释放。

TStringList *StringList;
try
{
StringList=new TStringList();
}
__finally
{
StringList->Free();
}

象这种，如果是在new TStringList的时候，由于内存不足等原因，则导致不成功，同样会执行finally，则会有什么情况？StringList是一个无效的指针，去执行Free，导致的将可能是内存访问违例，甚至会引发线程崩溃。


虽然很多人都有使用try ... finally的习惯，为的就是保证内存被释放或者锁定的资源出现异常也能被解锁，但是使用不当也会带来严重的问题，或者说这个问题本身是不必要的。相反，换成下面的结构：
TStringList *StringList=new TStringList();
try
{

}
__finally
{
StringList->Free();
}

当在new的时候就出现异常，根本就不用担心会执行到try，更不用担心执行到__finally。而会直接跳到外层的异常处理结构当中。

去年的时候，接手公司一个旧的项目，当时某高人写的代码，首先是如楼上，并且允许创建的线程是无限的，于是用户配置线程数达1.5k（还有其它的服务程序在同一机器运行，所以实际创建的线程数量只到1.2k就上不去了），从而由于try(create)finally (free) 的结构，而导致异常。当时承载的用户量是3.5k。出了问题就让查，结果就是查不出个所以然来。接手之后，我是很偶然地发现了使用的是这种结构（由于代码特别长，并且是后期加入的try...finally，代码显得有些乱）。

[tsk]

受益良多。