多线程引用计数问题(避免坑爹)

本文探讨了多线程环境下引用计数可能导致的问题,特别是当引用计数在不同线程中增加和减少时,可能会导致对象被错误地删除。通过分析代码和反汇编,揭示了在特定情况下,`InterlockedIncrement`和`InterlockedDecrement`可能不足以防止双重删除。提出了两种解决方案,包括强关键区处理和改进的`AddRef`算法,并强调了使用智能指针的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

你没有注意到细节

-多线程引用计数问题

         其实写这篇文章完全是偶然所得,桌面安全有一套比较严格的测试平台,整个这套测试平台是建立的Appverifer的基础之上。而且,这套测试平台可以模拟出比较极限的测试情况,比如强压力测试。也是在解决一个bug的时候,多像了一些

         我们在写程序的时候,可能会考虑到一般鸭梨情况,但是如果鸭梨大了可能完全是另外一种程序运行场景,尤其在多线程场景下。对于编程的要求肯定不一致,而且,有些情况就算是鸭梨不大,这个多线程bug也可能会出来坑爹。我们的程序毕竟是面向千万用户,从概率上来讲有可能一千个用户出现问题。现在可是微博时代,传播起来,也会是很难收拾的局面。

        

好吧,废话少说,我来具体展开一下吧。

 

         场景是这样的,我们都知道引用计数是一种比较不错的内存管理方式,使用这个对象的时候我们就将计数加一,不使用了就减一,最后等到引用计数为0的时候,那就释放掉这个对象。不错,当初发明这种方法的人真是个聪明的家伙。像下面这样实现:

        

         ULONG SomeObject::AddRef()

{

    return ++m_ulRef;

}

 

ULONG SomeObject::Release()

{

    if (--m_ulRef < 0)

    {

         delete this;

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值