iOS 多线程使用总结（很实用）

每次准备开始新的航行，总是要复习一遍算法啊，多线程啊，内存管理啊之类的理论和应用知识，这次把他们整理成文档，方便以后的学习和不断的积累进步。
        多线程给我留下的是痛苦的记忆，当时在上家创业公司的最后阶段，就是被Feature Phone上面的多线程方案导致bug丛生，搞的焦头烂额。

        (一). 多线程的应用
        由于一直做手机应用程序的开发，所以我接触到的多线程方案很少，总结下来只用来解决2类问题：
        问题1. 同步问题
        问题2. 耗时计算问题
        所谓的同步问题是指，比如在多媒体实时系统中，解码模块与播放模块之间的关系，解码模块解码完毕，播放模块就需要进行绘制或者播放声音。一种方案是异步方案，解码完毕通知播放模块播放，或者轮询方案，解码后将数据放入缓冲区，播放模块轮询（用timer机制），这些方案的实时性都无法保证，因此如果对实时性要求较高的应用，用线程同步机制是最好的方案：解码器解码，解锁，播放器播放，继续等待数据。这就是多线程模型中的最基本模型：生产者消费者模型。[详情见2.1]
        而耗时的计算问题则比较普遍，尤其是手机上的图片应用，比如图片浏览的应用，当用户快速拖动scroll view的时候，如果加载图片文件，解码，绘制整个过程的时间超过16ms（60fps的要求），就会有卡顿，不够流畅，这时候就需要用后台线程做这些加载文件，解码等费时的操作。

        (二). iOS系统提供的多线程方案
        iOS系统提供了n多的线程方案，从最底层POSIX库支持，到NSThread，再到Operation Queue，最后到最方便的GCD。
        1. iOS支持POSIX线程库，以基本的生产者消费者模型为例（见[参考代码：https://github.com/zteshadow/threadStudy]里面的POSIX工程，所有的代码都是iOS版本的实现，在XCode5.0上面编译），实现这个模型要注意需要3个lock，一个是用来保护对缓冲区的读写操作的，一个是当缓冲区已满的时候锁住生产者，一个是当缓冲区为空的时候锁住消费者。注意iOS不支持匿名锁，所以需要使用sem_open来创建锁。POSIX线程pthread1995年发布，60个函数.
        创建：pthread_create
        终止：
            自己返回：隐式终止
            自己调用pthread_exit：显示终止
            被别人调用pthread_cancel：被终止
        回收线程资源：
            pthread_join：阻塞等待线程退出，回收资源：栈，控制结构等
        分离和结合：
            默认创建的线程是可结合的，由创建者回收资源，可以调用pthread_detach来分离线程，让系统回收资源。
        2. NSThread只是比pthread高一层的objective-c抽象，用起来比较复杂，可能还需要维护一个runloop，runloop的源等等，如果为了解决问题2，是完全没有必要使用NSThread的。
        NSThread alloc ，start：可以先建立，再配置，再执行
        NSThread detachNewThreadSelector：立即开始执行

        3. Operation Queue
        示例代码演示了一个场景：将一个耗时操作（耗时5秒钟）发送给主线程之外的线程来执行（见[参考代码：https://github.com/zteshadow/threadStudy]里面的NSOperationQueue工程)，该工程里在controller的构造函数里面创建了operation queue，在按钮的响应函数里面创建operation，然后发送给queue去处理，如果设置queue的maxConcurrentOperationCount大于1，则会由系统线程池中的多个线程从queue里面取出operation并发执行，否则顺序执行，Operation Queue是iOS2引入的。
        4. GCD
        解决上面3同样的问题，可以使用GCD，见[参考代码：https://github.com/zteshadow/threadStudy]里面的GCD工程。可以看到只要把创建NSInvocationOperation，再add到queue换成dispatch_async就可以了，要将现有的基于Operation Queue的代码改成GCD代码，非常简单——不过似乎也没有什么理由这么做。如果不是迁移Operation Queue的代码，而是新建的代码，那么基于GCD要比Operation Queue简单。dispatch_get_global_queue是个并发执行的queue，如果要顺序执行，需要自己用dispatch_queue_create创建queue（iOS4引入的2010年）。

GCD中的一些知识点：
        dispatch_barrier_async工作机制是怎样的？如何实现？
        queue中的其他block已经开始在各自分配的线程执行，当从queue检出一个barrier时，是等待其他的block都执行完毕再执行barrier，此时不会并发执行其他的block，直到该barrier执行完毕。 这相当于给当前已经运行的bock们加了一个group和notify，在notify里面执行了barrier，然后再执行barrier下面的block——实际上GCD的实现中的确如此。
        dispatch_queue_create 默认是serial的queue，可以用参数：DISPATCH_QUEUE_CONCURRENT，创建并发queue，串行queue——每个对应会创建一个thread，如果持续的增加串行queue，比如说10000个串行queue，那么系统就要生成10000个线程来进行调度，这会严重影响系统性能，甚至导致崩溃，而并发queue，随着dispatch的block的增加，系统会根据当前的core的数量以及当前CPU的usage等综合资源，选择创建新的thread或者是用现有的thread进行调度。

        (三).线程间的通信
        1. 上面的3和4中，主线程将task发送给系统中的辅助线程执行，当执行完毕如果需要通知主线程的，可以使用：performSelectorOnMainThread，或者使用GCD中的dispatch_async让block在dispatch_get_main_queue上运行。
        2. 如果自己创建了NSThread，那么可能需要讲一下runloop。顾名思义，runloop就是一个循环，如果没有runloop，那么我们创建的线程一般需要自己做一个循环来等待事件的发生，类似于这样：
        while (wait_for_event)
        {
            do_some_thing
        }
        在没有事件的时候阻塞，有事件处理事件。iOS为我们提供了一个runloop代替这个自己做的循环，我们可以调用runloop的run进入循环。就像我们自己创建循环一样，runloop也需要一个等待的事件，如果没有等待事件（runloop的源），那么runloop就会直接返回，然后线程结束了。runloop的源可以是个timer源，也可以是事件源，我们可以自己定义源，也可以使用message port作为输入源。NSPort有3种类型：NSMachPort，NSMessagePort和NSSocketPort，文档中不建议使用NSMessagePort，而且好像在iOS7中cocoa去掉了对NSPortMessage的支持，原因不详。这样就不能用cocoa中的message port了，可以使用core foundation中的message port，不过稍微麻烦一些见[参考代码：https://github.com/zteshadow/threadStudy]中的CFMessagePortRef工程。注意外部源用signal来发出信号，这个和message port稍有不同，signal只有0和1的状态，而message port有个消息队列可以存储多个消息，而signal只能发生一次。例如，我们用自定义的源通知辅助线程进行耗时计算，signal之后，线程运行耗时函数，此时如果主线程再发送一个signal进行第二个操作，那么当上一个耗时操作结束后，辅助线程不会进行第二个操作，原因是辅助线程得到signal之后进行耗时操作，结束后将signal清除，而没有消息队列的概念，如果需要可以自己实现。而message port则有消息队列，能处理多个请求。runloop一般我们显式用到的地方就2个：NSTimer和URLRequest. runloop是实现performOnThread的基础——目标thread必须有runloop在运行，因为该实现的原理是基于runloop源的
        3. 同步的代价
        posix_mutext
        NSLock：lock, unlock
        @synchronized
        在iPhone4S上面进行100次的NSMutableArray的插入和取出测试取均值得到如下结果：
        @synchronized为11ms，NSLock 8~9ms，
        用GCD，也就是插入用barrier_async，get用sync，其实是和lock差不多的，大概比synchronized节省40%

        (四).快速拖动图片的解决方案
        快速拖动的线程方案需要和cache配合使用，一个cell需要获取图片的时候，先检查cache，如果命中则使用cache的图片，否则使用默认图片，然后在线程中加载图片，进行解码，然后在main queue中设置图片。【注意】这个方案如果不注意会有个bug，由于cell是复用的，而dispatch是并发执行的，那么可能会有cell的image顺序错乱的问题。有2个方案可以解决：1是每次cell获取新的图片时，将旧有的操作cancel掉——虽然block执行起来就无法停止，但是我们还是可以在block的执行代码中做判断控制是否要进行图片的切换操作，2是用顺序队列执行dispatch。

        (五). Timer
        NSTimer是基于runloop的，创建之后，只有
［NSRunLoop currentRunloop] addTimer:timer1 forMode:NSDefaultRunLoopMode]，才能开始工作，对于那些没有runloop的用户线程，就无法使用这个timer了，这时可以用基于dispatch queue的
dispatch_source_set_timer。

        (六). 总结
        解决问题1，需要使用线程，个人没有用过，但感觉使用POSIX线程更清晰明了。
        解决问题2，使用Operation Queue和GCD就够了，Operation Queue是iOS2.0加入的，而GCD是iOS4.0加的新特性，基于block在参数传递函数封装等方面比Operation更灵活，基本可以替换掉Operation Queue——不过，如果需要支持操作的cancel以及各个操作之间的依赖关系，那么只能使用Operation Queue——这个没用过。