philm-iOS-wiki
  • 介绍
  • 网络层
    • 说明
  • UI
    • 说明
    • 在ios7以前使用ColorSpace的坑
    • UITableView偏移异常问题
    • drawRect时单独设置文字阴影无效
    • Xcode9下相册访问权限问题
    • 避免同时点击多个Button
    • scroll上的button延迟响应问题
    • uibutton触发边界事件
    • ios 11 上tableview 改动
    • YYImage 显示指定区域的图片
  • 数据持久化
    • 说明
  • 其它
    • 取消延迟执行之坑
    • NSString 转换 float 的精度问题
  • 每周阅读
    • 目录
    • 深入思考NSNotification
    • gitBook使用小助手
    • iOS App签名的原理
    • 响应链
    • iOS10跳转系统到设置页
    • SDWebImage下载高清图内存问题
    • iOS圆角避免离屏渲染
    • 常用的延时调用
    • iOS 神经网络
    • SDWebImage缓存策略
    • 3Dtouch
    • 为什么 Objective-C 对象存储在堆上而不是栈上
    • 深入浅出理解视频编码H264结构
    • CATextLayer学习
    • cocoaPods
    • 任意网站支持RSS
    • Metal简介
    • 动态更改icon
    • CAReplicatorLayer
    • 增加点击间隔
    • 勒索病毒当道的时代
    • iOS常用宏定义
    • Metal实现YUV转RGB渲染视频
    • 获取当前下载的app及下载进度
    • OpenGL ES 三种类型修饰 uniform attribute varying
    • 技术部门引入OKR
    • 基于runloop的线程保活、销毁与通信
    • 深入理解哈希表
    • TOLL-FREE BRIDGING 和 UNMANAGED
    • 开发者能拿到的标识符
    • Swift自定义LOG
    • 系统通知整理
    • iOS 中的 imageIO 与 image 解码
    • CGImageRef基本介绍及方法说明
    • Swift 3.0 语法
    • webview加载部分网页
    • 在CAAnimation中暂停动画
    • 把代码迁移到协调器上
    • ios11API更新整理
    • 非越狱iOS设备的远程控制实现原理
    • 关于本地化
    • swift命名空间
    • CoreML与coremltools体验
    • 力学动画
    • Swift 4官方文档中文版: The Basic(上)
    • swift 中的KVO用法
    • GPUImage的图像形变设计(简单形变部分)
    • iOS响应式架构
    • 移动端图片上传旋转、压缩的解决方案
    • AVFoundation使用指南AVAssert使用
    • 过渡动画
    • 谈谈 MVX 中的 Model
    • AVFoundation编程-AVPlayer使用
    • GPUImage的图像形变设计(复杂形变部分)
    • What's New in LLVM 9
    • ios的事件机制
    • GPUImage源码解读(一)
    • GPUImage源码解读(二)
    • iOS 启动优化
    • 模块化 Swift 中的状态
    • swift中的let和var背后的编程模式
    • Swift Runtime动态性分析
    • RAC下的响应式编程
    • GPUImage源码解读(三)
    • 如何准确判断webView是否加载完成
    • NSObject的+load和+initialize详解
    • ios8以后设置启动图
    • GPUImage源码解读(四)
    • Swift自动闭包
    • IOS11新特性
    • GPUImage源码解读(五)
    • 理解 OC 内部的消息调用、消息转发、类和对象
    • 修饰符
    • IOS 切面统计事件解耦
    • GPUImage源码解读(六)
    • CoreImage介绍
    • 影响Core Animation性能的原因
    • Instruments中的动画工具选项介绍
    • GPUImage源码解读(七)
    • Xcode 7新的特性Lightweight Generics 轻量级泛型与__kindof修饰符
    • GPUImage源码解读(八)
    • Core Image之自定 Filter
    • iOS通用链接
    • 谈nonatomic非线程安全问题
    • 深拷贝与浅拷贝
    • CIKernel 介绍
    • iOS11适配
    • GPUImage源码解读(九)
    • CVPixelBufferCreate使用的坑
    • ios一窥并发底层
    • ARKit进阶:物理世界
    • ARKit的工作原理及流程介绍
    • UI线程卡顿监控
    • FBKVOController使用
    • GPUImage源码解读(十)
    • WKWebView在ios11崩溃问题解决方法
    • 微信iOS SQLite源码优化实践
    • HEIF 和 HEVC 研究
    • 谈谈 iOS 中图片的解压缩
    • 提升 iOS 开发效率! Xcode 9 内置模拟器的9个技巧
    • ObjC和JavaScript的交互,在恰当的时机注入对象
    • iOS数据保护
    • iOS11中网络层的一些变化(Session707&709脱水版)
    • GPUImage源码解读(十一)
    • 一种避免 iOS 内存碎片的方法
    • pods的原理
    • GPUImage源码解读(十二)
    • GPUImage源码解读(十三)
    • iOS 11 Layout的新特性
    • iOS应用瘦身方法思路整理
    • GPUImage源码解读(十四)
    • CAEmitterLayer属性介绍
    • 浅析移动蜂窝网络的特点及其省电方案
    • 如何在 table view 中添加 3D Touch Peek & Pop 功能
    • iOS中锁的介绍与使用
    • NSLog效率低下的原因及尝试lldb断点打印Log
    • GPUImage源码解读(十五)
    • GPUImage源码解读(十六)
    • CADisplayLink
    • GPUImage源码解读(十七)
    • CADisplayLink
    • 老生常谈category增加属性的几种操作
    • 30行代码演示dispatch_once死锁
    • GPUImage源码解读(十八)
    • YYImage设计思路
    • GPUImage源码解读(十九)
    • 深入理解Tagged Pointer
    • iOS 11:WKWebView内容过滤规则详解
    • Swift语法对编译速度的影响
    • GPUImage源码解读(二十)
    • GPUImage源码解读(二十一)
    • iOS App间常用的五种通信方式
    • YYCache深入学习
    • 冲顶大会插件
    • iOS高性能图片架构与设计
    • YUV颜色编码解析
    • iOS传感器:App前后台切换后,获取敏感信息使用touch ID进行校验
    • GPUImage源码解读(二十二)
    • GPUImage源码解读(二十三)
    • 从零开始的机器学习 - Machine Learning(一)
    • 从零开始的机器学习 - Machine Learning(二)
    • GPUImage源码解读(二十四)
    • Objective-C消息转发机制
    • iOS 程序 main 函数之前发生了什么
    • MMKV--基于 mmap 的 iOS 高性能通用 key-value 组件
    • Objective-C 消息发送与转发机制原理
    • 谈Objective-C block的实现
    • GPUImage源码解读(二十五)
    • podfile语法
    • 轻量级低风险 iOS 热更新方案
    • 使用objection来模块化开发iOS项目
    • swift 中delegate的使用注意
    • 使用appledoc自动生成api文档
    • UITextChecker的使用
    • ARKit 如何给SCNNode贴Gif图片
    • Unity与iOS平台交互和原生插件开发
    • SceneKit编程珠玑
Powered by GitBook
On this page
  • 背景
  • Crash的堆栈分析
  • 探索nonatomic非线程安全的原因
  • 总结
  1. 每周阅读

谈nonatomic非线程安全问题

背景

由于我对SDWebImage这块比较熟悉,并且基于SDWebImage封装了一层对业务更友好的HTSWebImage库。所以一直以来SDWebImage的相关Crash都是我在负责。

由于图片加载频繁使用到多线程,所以SDWebImage的crash总是时不时会带来些惊喜(惊悚)。也有不少常年未解之谜,明明看上去没有任何问题,但是就是发生了EXC_BAD_ACCESS。

近日,与李卓立同学聊到SDWebImage的crash问题。提到了一个SDWebImageDownloaderOperation类中nonatomic属性imageData非线程安全,而导致的crash。

Crash的堆栈分析

一直以来都知道nonatomic是非线程安全的,但是在这之前,从未真正意识到这个问题,也没有将crash往这方面想过。我们先来看看crash的堆栈。

堆栈1:

Crashed: NSOperationQueue 0x174429d60 :: NSOperation 0x17104ce10 (QOS: DEFAULT)
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000cbd0dbec8
 Raw Text
0   libobjc.A.dylib 
objc_retain + 16
1   LiveStreaming   
SDWebImageDownloaderOperation.m line 428
-[SDWebImageDownloaderOperation URLSession:task:didCompleteWithError:]
2   LiveStreaming   
SDWebImageDownloader.m line 311
-[SDWebImageDownloader URLSession:task:didCompleteWithError:]

代码:

427        if ([self callbacksForKey:kCompletedCallbackKey].count > 0) {
428            if (self.imageData) {
429                UIImage *image = [UIImage sd_imageWithData:self.imageData];
430                NSString *key = [[SDWebImageManager sharedManager] cacheKeyForURL:self.request.URL];
431                image = [self scaledImageForKey:key image:image];

堆栈2:

Crashed: NSOperationQueue 0x1702386a0 :: NSOperation 0x170a57cd0 (QOS: DEFAULT)
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x00000000ac18beb8
 Raw Text
0   libobjc.A.dylib 
objc_msgSend + 16
1   LiveStreaming   
SDWebImageDownloaderOperation.m line 302
-[SDWebImageDownloaderOperation URLSession:dataTask:didReceiveData:]
2   LiveStreaming   
SDWebImageDownloader.m line 291
-[SDWebImageDownloader URLSession:dataTask:didReceiveData:]

代码:

301 - (void)URLSession:(NSURLSession *)session dataTask:(NSURLSessionDataTask *)dataTask didReceiveData:(NSData *)data {
302     [self.imageData appendData:data];
303
304     if ((self.options & SDWebImageDownloaderProgressiveDownload) && self.expectedSize > 0) {
305

一眼看去,什么鬼。堆栈1,crash在428行,if (self.imageData) 怎么也能crash,ARC下自动管理内存,self.imageData用法没毛病呀,怎么又crash在objc_retain了。再来看看堆栈2,这又是怎么回事,[self.imageData appendData:data];出现了EXC_BAD_ACCESS。又是self.imageData出了毛病。

可是为什么self.imageData会出毛病呢?我们来看看imageData属性定义的方式。

@property (strong, nonatomic, nullable) NSMutableData *imageData;

nonatomic非原子性,也就意味着非线程安全,一直以来大家都是习惯使用nonatomic。这样使用保证了效率,但是却会牺牲掉安全性。在这里就是因为nonatomic非线程安全,多线程同时调用到属性的setter和getter方法就有可能发生crash。

目前项目中因为self.imageData属性而导致的crash,每周大约有700例左右,影响面积非常广大,是项目中最严重的几个crash之一。小疏忽引发大问题,而且如果不往nonatomic方面想,这种问题真的非常难查。

探索nonatomic非线程安全的原因

为什么nonatomic是非线程安全的,这样的crash是怎么发生的呢?我们来看看runtime的源码:

//getter:
id objc_getProperty(id self, SEL _cmd, ptrdiff_t offset, BOOL atomic) {
    if (offset == 0) {
        return object_getClass(self);
    }

    // Retain release world
    id *slot = (id*) ((char*)self + offset);
    if (!atomic) return *slot;

    // Atomic retain release world
    spinlock_t& slotlock = PropertyLocks[slot];
    slotlock.lock();
    id value = objc_retain(*slot);
    slotlock.unlock();

    // for performance, we (safely) issue the autorelease OUTSIDE of the spinlock.
    return objc_autoreleaseReturnValue(value);
}
//setter:
void objc_setProperty_nonatomic(id self, SEL _cmd, id newValue, ptrdiff_t offset)
{
    reallySetProperty(self, _cmd, newValue, offset, false, false, false);
}

static inline void reallySetProperty(id self, SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
    if (offset == 0) {
        object_setClass(self, newValue);
        return;
    }

    id oldValue;
    id *slot = (id*) ((char*)self + offset);

    if (copy) {
        newValue = [newValue copyWithZone:nil];
    } else if (mutableCopy) {
        newValue = [newValue mutableCopyWithZone:nil];
    } else {
        if (*slot == newValue) return;
        newValue = objc_retain(newValue);
    }

    if (!atomic) {
        oldValue = *slot;
        *slot = newValue;
    } else {
        spinlock_t& slotlock = PropertyLocks[slot];
        slotlock.lock();
        oldValue = *slot;
        *slot = newValue;        
        slotlock.unlock();
    }

    objc_release(oldValue);
}

根据源码,我们可以看到,getter是不会对属性进行retain的,假设当getter执行后,切换到另一个线程,执行setter,setter会对oldValue release,导致oldValue释放。再切回执行getter的线程,getter用到的是已经释放的oldValue。就会发生EXC_BAD_ACCESS的crash。

一般情况下,getter执行后,会在外部对getter获取的属性进行retain,也就是调用objc_retain。但是也许就在getter发生之后,objc_retain之前其他线程执行了setter。这时候,就会导致objc_retain产生EXC_BAD_ACCESS,例如堆栈1,这种crash发生的概率不大,但是架不住SDWebImage被频繁使用。特别是feed上,频繁调用SDWebImage,导致多线程切换。

那么atomic会不会发生问题呢?根据源码,在获取到属性时,atomic下getter会立即对value进行retain,即使setter对oldValue release了。由于getter已经进行retain,属性不会立即释放。只有使用完成之后才会释放。所以atomic会可以保证属性的线程安全

总结

一直以来,大家都习惯性使用nonatomic了,平时不会太注意,小疏忽产生大问题。这个crash在SDWebImage上一直有人上报,也遗留了非常长的时间,一直未解决,如果不是特别注意nonatomic,很难想到crash的原因。而且这类crash很难复现。只能通过线上堆栈来看。更加增加了修复crash的难度。so,以后对于处理多线程的问题,要记得不要再用nonatomic了哦~

PreviousiOS通用链接Next深拷贝与浅拷贝

Last updated 7 years ago