数据源同步

数据源同步

数据源同步问题：删除一条数据（主线程）--> 数据源 < --  LoadMore (子线程)   （涉及到了多线程对共享数据源的一个同步问题，面试的时候可能会被问到 如何解决这种tableView在多线程环境下的去修改或者访问数据源这样的同步问题）

$\color{red}{方法1:并发访问、数据拷贝} $

① 比方说现在有主线程和子线程，我们在做数据拷贝的时候，一般在主线程当中。

② 拷贝之后呢会把拷贝的结果给子线程来使用，同时在子线程里进行新数据的网络请求、数据解析和预排版等。

 ③ 在子线程操作的同时，我们在主线程删除一行数据（为了防止和子线程数据不同步，需要记录删除操作）、reload UI后，此条数据会消失不见，如果还有时间，主线程会做other work一切其他的操作。

 ④ 子线程将要返回数据，更新主线程UI的时候，同步删除操作，在子线程里面把拷贝过来的数据也做一次删除的操作。

 ⑤ 然后回到主线程去reload UI。

$\color{red}{方法2:串行访问} $

比方说有主线程和子线程，既然是串行访问，就要使用到GCD当中的一个串行队列。

① 此时比如说子线程正在进行网络请求、数据解析，然后它会把网络数据请求过来的一部分在串行队列当中进行新增数据预排版，当然这一过程是在子线程当中进行的。

② 如果在这一过程当中，在主线程里面删除某一行数据的话，需要以同步的方式在串行队列当中进行处理，此时如果子线程正在进行新增数据预排版等操作的时候，那么主线程要等一小会Waiting，然后在串行队列当中,前一个block任务执行完成之后，然后去同步主线程发送的任务数据删除。

③ 把数据删除同步之后，再回到主线程reload UI 。这样就能保证无论是主线程还是子线程，对tableView的数据源的操作都是在串行队列中进行的，就可以保证数据的一个同步的问题，避免UI刷新错乱的一个现象。

总结：两种方案各有利弊，比如②串行访问方案，要求在子线程处理任务特别耗时的时候呢，我们某一个删除动作可能有一定的延迟。对于①并发访问、数据拷贝来说呢，有数据同步的一个操作（记录数据删除的一个动作），然后我们还需要大量数据源的一个拷贝，内存的开销是有一定的问题。所以应该根据实际业务选择哪种方案。