189 8069 5689
在java5以前实现多线程有两种方法（继承Thread类和实现Runnable接口） 它们分别为： 使用new Thread()和new Thread(Runnable)形式 第一种直接调用thread的run方法，所以，往往使用Thread子类，即new SubThread()。 第二种调用 Runnable的run方法。 第一种： new Thread(){}.start();这表示调用Thread子类对象的run方法，new Thread(){}表示一个Thread的匿名子类的实例对象，子类加上run方法后的代码如下： new Thread(){ public void run(){ } }.start(); 第二种： new Thread( new Runnable(){} ).start(); 这表示调用Thread对象接受的Runnable对象的run方法，new Runnable(){}表示一个Runnable的匿名子类的实例对象, runnable的子类加上run方法后的代码如下： new Thread(new Runnable(){ public void run(){ } } ).start();
创新互联公司专注于网站建设|企业网站维护|优化|托管以及网络推广，积累了大量的网站设计与制作经验，为许多企业提供了网站定制设计服务，案例作品覆盖水处理设备等行业。能根据企业所处的行业与销售的产品，结合品牌形象的塑造，量身策划品质网站。
1.goole开源
2.iOS基础知识
;page=1
3.OC的缺陷和陷阱
4.文顶顶博客园
5.FaceBook
6.objc中国
7.唐巧的技术博客
8.念茜的博客
9.code4app
10.cocoaChina
11.IT 社区
12.C博客
13.CocoaPods的安装及使用
14.标准时间与时间戳相互转化
15.博客 loadView、viewDidLoad及viewDidUnload的关系
16.iOS即时通讯语音聊天本地音频处理
17.承影博客
18.常用加密
19.正则表达式
20.iphone开发过程中调试多次release问题
21.使用 Xcode 和 Instruments 调试解决 iOS 内存泄露
22.iOS开发中常见的一些bug
23.玩转swift
24.友盟分享
25.objc中国
26.ViewController的切换
27.iOS 平台 Cocos2d-x 项目接入新浪微博 SDK 的坑
28.joosonmao的专栏（里面的文章都很棒）
29.移动IM（环信）
环信XMPP：
30.各种错误汇总博客园
31.菜鸟笔记
;page=1
32.开发者账号注册和支付
33.在Xcode中使用Git进行源码版本控制
34.PNChart(图像绘画)
35.微信公众平台
36.常用加密
37.cocoaPod相关网址：
38.2014年整理的IOS开发常用库
39.挺好的一个网站
40、响应者链
41、改变UITabBar的背景色
;utm_medium=referral
42、 IOS 集成到支付宝的步骤及问题
43、 XMPP 协议实现原理介绍
44、 iOS开发多线程篇—多线程简单介绍
45、KVC 与 KVO理解
46、 iOS 设计模式之单例模式
47. 一些第三方库的了解
线程和进程在我们开发中，跟我们一直形影不离，那么什么是进程，什么是线程，它们又有什么关系，这篇文章将为您简单介绍。
线程概念
进程概念
地址空间：同⼀进程的线程共享本进程的地址空间（ TLS是本地的线程栈存空间，线程的局部空间是某些操作系统为线程提供的私有空间，只具备有限的容量，并不属于线程，由操作系统单独安排的 ），⽽进程之间则是独⽴的地址空间。
资源拥有：同⼀进程内的线程共享本进程的资源如内存、I/O、cpu等，但是进程之间的资源是独⽴的。
优点：
缺点：
时间⽚的概念：CPU在多个任务直接进⾏快速的切换，这个时间间隔就是时间⽚。
多线程同时执行
如果线程非常多
互斥锁⼩结
互斥锁参数
nonatomic⾮原⼦属性
atomic原⼦属性(线程安全)，针对多线程设计的，默认值，保证同⼀时间只有⼀个线程能够写⼊(但是同⼀个时间多个线程都可以取值)
atomic本身就有⼀把锁(⾃旋锁)
单写多读：单个线程写⼊，多个线程可以读取
atomic：线程安全，需要消耗⼤量的资源
nonatomic：⾮线程安全，适合内存⼩的移动设备
iOS开发建议
所有属性都声明为nonatomic
尽量避免多线程抢夺同一块资源
尽量将加锁，资源抢夺的业务逻辑交给服务器处理，减少APP的压力
这篇文章简单介绍了线程与进程的概念，烦请大家不吝赐教。
在使用GCD的时候，我们会把需要处理的任务放到Block中，然后将任务 追加 到相应的队列里面，这个队列，叫做Dispatch Queue。然而，存在于两种Dispatch Queue，一种是要等待上一个执行完，再执行下一个的Serial Dispatch Queue，这叫做串行队列；另一种，则是不需要上一个执行完，就能执行下一个的Concurrent Dispatch Queue，叫做并行队列。这两种，均遵循FIFO(先进先出)原则。
那么，并行队列又是怎么在执行呢？
虽然可以同时多个任务的处理，但是并行队列的处理量，还是要根据当前系统状态来。如果当前系统状态最多处理2个任务，那么1、2会排在前面，3什么时候操作，就看1或者2谁先完成，然后3接在后面。
串行与并行针对的是队列，而同步与异步，针对的则是线程。 最大的区别在于，同步线程要阻塞当前线程，必须要等待同步线程中的任务执行完，返回以后，才能继续执行下一任务，整个过程是不会创建新线程的；而异步线程则是不用等待，会在新开启的线程中执行任务(执行主队列的任务除外，主队列的任务在主线程中执行)。
分析：
首先执行任务1，这是肯定没问题的，只是接下来，程序遇到了同步线程，那么它会进入等待，等待任务2执行完，然后执行任务3。但这是队列，有任务来，当然会将任务加到队尾，然后遵循FIFO原则执行任务。那么，现在任务2就会被加到最后，任务3排在了任务2前面，问题来了：
任务3要等任务2执行完才能执行，任务2又排在任务3后面，意味着任务2要在任务3执行完才能执行，所以他们进入了互相等待的局面。【既然这样，那干脆就卡在这里吧】这就是死锁。
分析：
首先执行任务1，接下来会遇到一个同步线程，程序会进入等待。等待任务2执行完成以后，才能继续执行任务3。从 dispatch_get_global_queue 可以看出，任务2被加入到了全局的并行队列中，当并行队列执行完任务2以后，返回到主队列，继续执行任务3。
分析：
这个案例没有使用系统提供的串行或并行队列，而是自己通过 dispatch_queue_create 函数创建了一个 DISPATCH_QUEUE_SERIAL 的串行队列。执行任务1；遇到异步线程，将【任务2、同步线程、任务4】加入串行队列中。因为是异步线程，所以在主线程中的任务5不必等待异步线程中的所有任务完成；因为任务5不必等待，所以2和5的输出顺序不能确定；任务2执行完以后，遇到同步线程，这时，将任务3加入串行队列；又因为任务4比任务3早加入串行队列，所以，任务3要等待任务4完成以后，才能执行。但是任务3所在的同步线程会阻塞，所以任务4必须等任务3执行完以后再执行。这就又陷入了无限的等待中，造成死锁。
分析：
首先，将【任务1、异步线程、任务5】加入Main Queue中，异步线程中的任务是：【任务2、同步线程、任务4】。所以，先执行任务1，然后将异步线程中的任务加入到Global Queue中，因为异步线程，所以任务5不用等待，结果就是2和5的输出顺序不一定。然后再看异步线程中的任务执行顺序。任务2执行完以后，遇到同步线程。将同步线程中的任务加入到Main Queue中，这时加入的任务3在任务5的后面。当任务3执行完以后，没有了阻塞，程序继续执行任务4。
分析：
和上面几个案例的分析类似，先来看看都有哪些任务加入了Main Queue：【异步线程、任务4、死循环、任务5】。在加入到Global Queue异步线程中的任务有：【任务1、同步线程、任务3】。第一个就是异步线程，任务4不用等待，所以结果任务1和任务4顺序不一定。任务4完成后，程序进入死循环，Main Queue阻塞。但是加入到Global Queue的异步线程不受影响，继续执行任务1后面的同步线程。同步线程中，将任务2加入到了主线程，并且，任务3等待任务2完成以后才能执行。这时的主线程，已经被死循环阻塞了。所以任务2无法执行，当然任务3也无法执行，在死循环后的任务5也不会执行。
线程的不安全是由于多线程访问和修改共享资源而引起的不可预测的结果。
ios多线程开发中为保证线程的安全常用到的几种锁： NSLock 、 dispatch_semaphore 、 NSCondition 、 NSRecursiveLock 、 @synchronized 。
WEAKSELF typeof(self) __weak weakSelf = self;
NSLock 是OC层封装底层线程操作来实现的一种锁，继承NSLocking协议。不能迭代加锁，如果发生两次lock，而未unlock过，则会产生死锁问题。
以车站购票为例，多个窗口同时售票（同步），每个窗口有人循环购票：
原子操作
原子操作是指不可打断的操作，也就是说线程在执行操作的过程中，不会被操作系统挂起，而是一定会执行完，
变量属性Property中的原子定义
一般我们定义一个变量@property (nonatomic ,strong)NSLock *lock;nonatomic：非原子性，不会为setter方法加锁，适合内存小的移动设备；atomic：原子性，默认为setter方法加锁（默认就是atomic），线程安全。
PS： 在iOS开发过程中，一般都将属性声明为nonatomic，尽量避免多线程抢夺同一资源，尽量将加锁等资源抢夺业务交给服务器。
NSCondition常用于生产者-消费者模式，它继承了NSLocking协议，同样有lock和unlock方法。条件变量有点像信号量，提供了线程阻塞和信号机制，因此可以用来阻塞某个线程，并等待数据就绪再唤醒程序。
信号量主要有3个函数，分别是：
注意： 正常的使用顺序是先降低然后提高，这两个函数通常都是成对出现。
本文主要参考了这篇文章(
)，并对其中所能理解的部分进行一一验证，以前没怎么写过类似的，如果有什么做的不好的地方还请大家多多见谅！
在多线程开发中，我们常用到GCD，这里探讨一下GCD任务的取消:
1.在iOS 8以后，系统给我们提供了这样的取消函数 dispatch_block_cancel，不过这个也只能用于dispatch_block_create创建的dispatch_block_t，我们试验一下：
这时肯定是任务都会执行的
接下来，把注释的那一行 dispatch_block_cancel(block1);打开，看看效果:
我们发现block1确实被取消掉了。这是dispatch_block_cancel的用法。
2.很多时候，我们的场景不会去用dispatch_block_create创建dispatch_block_t，这个时候我们若想取消一个任务，可以考虑用一个条件来做，满足条件则执行此任务，不满足则不执行，举个例子：
效果如下:
写到这里，这儿其实还隐藏了一个知识点，就是block的变量捕获，有兴趣或是不理解的朋友可以研究一下。(如下，为何输出不是20而是10)
3.过渡到NSOperation
NSOperation是对GCD的封装，底层也是GCD。
NSOperation给我们封装了更多的api，这是我在Xcode中提出来的:
我们可以发现它有状态属性，有取消方法，也有添加依赖方法等...这里我们还是先说取消吧，下面来给大家写个demo:
这时输出是:
因为正在执行的任务，NSOperation也是不能取消的，所以也是需要将cancel在start前调用的(就如同满足一个条件是否需要cancel一样，也可以满足条件不调用start)