iOS - 互斥锁&&自旋锁 多线程安全隐患(转载)

一、多线程安全隐患

资源共享
  一块资源可能会被多个线程共享,也就是多个线程可能会访问到一块资源
 比如多个线程访问同一个对象,同一个变量,同一个文件。
 当多线程访问同一块资源的时候,很容易引发数据错乱和数据安全问题
二、原子和非原子属性
 1>OC 在定义属性的时候有nonatomic和atomic两种选择
      * atomic:原子属性,为 setter 方法加锁
      * nonatomic:非原子属性,不会为 setter 方法加锁
        普通情况下都是在主线程做操作,所以一般都不会加锁。
  对比:
      * atomic:线程安全,需要消耗大量的资源
      * nonatomic:非线程安全,适合内存小的移动设备
 2>synchronized 与 atomic
     * synchronized:互斥锁
     * atomic:自旋锁
  共同点:都能保证同一时刻只能有一个线程操作锁住的代码
    区别
      互斥锁:当上一个线程的任务没有执行完毕的时候(被锁住),那么下一个线程会进入睡眠状态等待任务执行完毕,当上一个线程的任务执行完毕,下一个线程会.  自动唤醒然后执行任务。
      自旋锁:当上一个线程的任务没有执行完毕的时候(被锁住),那么下一个线程会一直等待(不会睡眠),当上一个线程的任务执行完毕,下一个线程会立即执行。
  自旋锁应用场景:比较适合做一些不耗时的操作
三、互斥锁
· 注意点:
     - 如果多线程访问同一个资源,那么必须使用同一把锁才能锁住
     - 在开发中,尽量不要加锁,能在服务端做尽量在服务端做,如果必须要加锁,一定要记住,锁的范围不能太大,哪里有安全隐患就加在哪里。
  技巧:因为必须使用同一把锁,开发中如果需要加锁,直接使用 self 即可。

@synchronized(self) {
//线程1进来之后,锁住,2和3都再外面等待
//1、查询剩余的票数 NSUInteger count = self.totalCount;
//2、判断是否还有余票
//2.1卖票
//3 、提示客户,没有票了
if (count>0) {
[NSThread sleepForTimeInterval:0.1];
self.totalCount = count-1;
NSLog(@"%@卖了一张票,还剩%zd票",[NSThread currentThread].name,self.totalCount);
}
else
{
NSLog(@"没票了");
break;
}
}
//解锁

四、自旋锁
注意点:
只会给 setter 方法加锁,并不会给getter方法加锁。

时间: 2024-10-15 11:59:44

iOS - 互斥锁&&自旋锁 多线程安全隐患(转载)的相关文章

互斥锁,自旋锁与自适应自旋锁

线程安全与锁的优化 互斥锁: 从 实现原理上来讲,Mutex属于sleep-waiting类型的锁.例如在一个双核的机器上有两个线程(线程A和线程B),它们分别运行在Core0和 Core1上.假设线程A想要通过pthread_mutex_lock操作去得到一个临界区的锁,而此时这个锁正被线程B所持有,那么线程A就会被阻塞 (blocking),Core0 会在此时进行上下文切换(Context Switch)将线程A置于等待队列中,此时Core0就可以运行其他的任务(例如另一个线程C)而不必进

Java线程并发中常见的锁--自旋锁 偏向锁

随着互联网的蓬勃发展,越来越多的互联网企业面临着用户量膨胀而带来的并发安全问题.本文着重介绍了在java并发中常见的几种锁机制. 1.偏向锁 偏向锁是JDK1.6提出来的一种锁优化的机制.其核心的思想是,如果程序没有竞争,则取消之前已经取得锁的线程同步操作.也就是说,若某一锁被线程获取后,便进入偏向模式,当线程再次请求这个锁时,就无需再进行相关的同步操作了,从而节约了操作时间,如果在此之间有其他的线程进行了锁请求,则锁退出偏向模式.在JVM中使用-XX:+UseBiasedLocking pac

可重入锁 自旋锁,看这一篇就够了!

在多线程编程中,锁是常用地控制并发的机制,对于临界区的资源,需要保证线程之间互斥地访问. 1. 可重入锁 可重入锁,也叫做递归锁,指的是多次对同一个锁进行加锁操作,都不会阻塞线程.实现思路:记录当前锁正在被哪个线程使用,采用计数来统计lock和unlock的调用次数.正常情况下,lock和unlock的调用次数应该相等,如果不相等就会死锁. public class Test implements Runnable { ReentrantLock lock = new ReentrantLock

可重入锁 & 自旋锁 & Java里的AtomicReference和CAS操作 & Linux mutex不可重入

之前还是写过蛮多的关于锁的文章的: http://www.cnblogs.com/charlesblc/p/5994162.html <[转载]Java中的锁机制 synchronized & 偏向锁 & 轻量级锁 & 重量级锁 & 各自> http://www.cnblogs.com/charlesblc/p/5935326.html <[Todo] 乐观悲观锁,自旋互斥锁等等> http://www.cnblogs.com/charlesblc/

检测闩锁/自旋锁争用

1.检测闩锁争用 SELECT wait_type,wait_time_ms,waiting_tasks_count,wait_time_ms/nullif(waiting_tasks_count,0) as avg_wait_time FROM sys.dm_os_wait_stats where wait_type like 'LATCH_%' OR wait_type like 'PAGELATCH_%' OR wait_type like 'PAGEIOLATCH_%' 2.检测自旋锁争

iOS 线程同步 自旋锁 OSSpinLock

#import "ViewController.h" #import <libkern/OSAtomic.h> @interface ViewController () @property (nonatomic,assign) int ticket; //@property (nonatomic,assign) OSSpinLock lock; @end @implementation ViewController - (void)viewDidLoad { [super

偏向锁+自旋锁+轻量级锁??????

首先了解对象头MARK(对象头标记,32位): 存储GC标记,对象年龄,对象Hash,锁信息(锁记录的指针,偏向锁线程的ID) 大部分情况是没有竞争的,所以可以通过偏向来提高性能 所谓的偏向,即锁会偏向于当前已经占有锁的线程 ,通过将对象头Mark的标记设置为偏向,并将线程ID写入对象头Mark 只要没有竞争,获得偏向锁的线程,在将来进入同步块,不需要做同步 ,当其他线程请求相同的锁时,偏向模式结束 -XX:+UseBiasedLocking 默认启用 在竞争激烈的场合,偏向锁会增加系统负担 ?

Java 中15种锁的介绍:公平锁,可重入锁,独享锁,互斥锁,乐观锁,分段锁,自旋锁等等(转)

Java 中15种锁的介绍 在读很多并发文章中,会提及各种各样锁如公平锁,乐观锁等等,这篇文章介绍各种锁的分类.介绍的内容如下: 公平锁 / 非公平锁 可重入锁 / 不可重入锁 独享锁 / 共享锁 互斥锁 / 读写锁 乐观锁 / 悲观锁 分段锁 偏向锁 / 轻量级锁 / 重量级锁 自旋锁 上面是很多锁的名词,这些分类并不是全是指锁的状态,有的指锁的特性,有的指锁的设计,下面总结的内容是对每个锁的名词进行一定的解释. 公平锁 / 非公平锁 公平锁 公平锁是指多个线程按照申请锁的顺序来获取锁. 非公

C# lock 语法糖实现原理--《.NET Core 底层入门》之自旋锁,互斥锁,混合锁,读写锁

原文:C# lock 语法糖实现原理--<.NET Core 底层入门>之自旋锁,互斥锁,混合锁,读写锁 在多线程环境中,多个线程可能会同时访问同一个资源,为了避免访问发生冲突,可以根据访问的复杂程度采取不同的措施 原子操作适用于简单的单个操作,无锁算法适用于相对简单的一连串操作,而线程锁适用于复杂的一连串操作 原子操作 修改状态要么成功且状态改变,要么失败且状态不变,并且外部只能观察到修改前或者修改后的状态,修改中途的状态不能被观察到 .NET 中,System.Threading.Inte