iOS中主佇列的同/非同步執行

阿新 • • 發佈：2018-12-14

主佇列是主線中的一個序列佇列，通常我們重新整理UI都會回到主佇列。下面我們來看一下主佇列同步執行和非同步執行會產生什麼樣的效果。

主佇列，非同步執行

//主佇列+非同步執行
//不會開啟新的執行緒，任務順序執行
-(void)test5{
    NSLog(@"主佇列+非同步執行");
    //global_queue 主佇列
    dispatch_queue_t queue = dispatch_get_main_queue();
    //dispatch_async 非同步執行
    dispatch_async(queue, ^{
        for (int i = 0 
; i < 10; i ++) {
            NSLog(@"1------%@",[NSThread currentThread]);
        }
    });
    dispatch_async(queue, ^{
        for (int i = 0; i < 10; i ++) {
            NSLog(@"2------%@",[NSThread currentThread]);
        }
    });
    dispatch_async(queue, ^{
        for (int i = 0; i < 10 
; i ++) {
            NSLog(@"3------%@",[NSThread currentThread]);
        }
    });
    NSLog(@"end");
}

列印結果：

2018-08-30 13:13:04.267741+0800 GCD_demo[2846:151142] 主佇列+非同步執行
2018-08-30 13:13:04.267853+0800 GCD_demo[2846:151142] end
2018-08-30 13:13:04.270849+0800 GCD_demo[2846:151142] 1------<NSThread: 0x604000077540>{number = 1, name = main} 

2018-08-30 13:13:04.270981+0800 GCD_demo[2846:151142] 1------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.271349+0800 GCD_demo[2846:151142] 1------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.271499+0800 GCD_demo[2846:151142] 1------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.271774+0800 GCD_demo[2846:151142] 1------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.271930+0800 GCD_demo[2846:151142] 1------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.272077+0800 GCD_demo[2846:151142] 1------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.272461+0800 GCD_demo[2846:151142] 1------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.272559+0800 GCD_demo[2846:151142] 1------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.272959+0800 GCD_demo[2846:151142] 1------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.273210+0800 GCD_demo[2846:151142] 2------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.273323+0800 GCD_demo[2846:151142] 2------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.273433+0800 GCD_demo[2846:151142] 2------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.273799+0800 GCD_demo[2846:151142] 2------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.274130+0800 GCD_demo[2846:151142] 2------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.274484+0800 GCD_demo[2846:151142] 2------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.274732+0800 GCD_demo[2846:151142] 2------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.274909+0800 GCD_demo[2846:151142] 2------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.275144+0800 GCD_demo[2846:151142] 2------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.275409+0800 GCD_demo[2846:151142] 2------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.275707+0800 GCD_demo[2846:151142] 3------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.276049+0800 GCD_demo[2846:151142] 3------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.276228+0800 GCD_demo[2846:151142] 3------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.277371+0800 GCD_demo[2846:151142] 3------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.277609+0800 GCD_demo[2846:151142] 3------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.277728+0800 GCD_demo[2846:151142] 3------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.277858+0800 GCD_demo[2846:151142] 3------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.277973+0800 GCD_demo[2846:151142] 3------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.278075+0800 GCD_demo[2846:151142] 3------<NSThread: 0x604000077540>{number = 1, name = main}
2018-08-30 13:13:04.278478+0800 GCD_demo[2846:151142] 3------<NSThread: 0x604000077540>{number = 1, name = main}

主佇列非同步執行時，會先執行完主執行緒上的程式碼，然後在主執行緒上順序執行任務，不會有新的執行緒產生，所有任務都是在主執行緒上完成的。

主佇列，同步執行

//主佇列+同步執行
//在主執行緒中執行時會死鎖，程式會崩潰
-(void)test6{
    //死鎖原因：同步對於任務是立刻執行的，當把第一個任務放進主佇列時，就會立即執行。可是主執行緒現在正在處理test6方法，任務需要等test6執行完才能執行，然後任務不執行完的話，test6方法也不算執行完，所以出現了test6需要等待任務執行完才能執行完，而任務又需要等待test6執行完才能執行。相互等待，死鎖！
    NSLog(@"主佇列+同步執行");
    //global_queue 主佇列
    dispatch_queue_t queue = dispatch_get_main_queue();
    //dispatch_async 同步執行
    //任務
    dispatch_sync(queue, ^{
        for (int i = 0; i < 10; i ++) {
            NSLog(@"1------%@",[NSThread currentThread]);
        }
    });
    dispatch_sync(queue, ^{
        for (int i = 0; i < 10; i ++) {
            NSLog(@"2------%@",[NSThread currentThread]);
        }
    });
    dispatch_sync(queue, ^{
        for (int i = 0; i < 10; i ++) {
            NSLog(@"3------%@",[NSThread currentThread]);
        }
    });
    NSLog(@"end");
}

以上方法直接在主執行緒中呼叫的話會造成死鎖，可以放到子執行緒中去執行，如使用如下方法呼叫：

dispatch_async(dispatch_queue_create("test", DISPATCH_QUEUE_SERIAL), ^{
        [self test6];
    });

列印結果：

2018-08-30 13:23:52.827501+0800 GCD_demo[2975:159890] 主佇列+同步執行
2018-08-30 13:23:52.830572+0800 GCD_demo[2975:159805] 1------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.830986+0800 GCD_demo[2975:159805] 1------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.831360+0800 GCD_demo[2975:159805] 1------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.831610+0800 GCD_demo[2975:159805] 1------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.831685+0800 GCD_demo[2975:159805] 1------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.831847+0800 GCD_demo[2975:159805] 1------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.831954+0800 GCD_demo[2975:159805] 1------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.832051+0800 GCD_demo[2975:159805] 1------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.832248+0800 GCD_demo[2975:159805] 1------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.832477+0800 GCD_demo[2975:159805] 1------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.833122+0800 GCD_demo[2975:159805] 2------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.833498+0800 GCD_demo[2975:159805] 2------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.833786+0800 GCD_demo[2975:159805] 2------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.834105+0800 GCD_demo[2975:159805] 2------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.834322+0800 GCD_demo[2975:159805] 2------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.834583+0800 GCD_demo[2975:159805] 2------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.834833+0800 GCD_demo[2975:159805] 2------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.835076+0800 GCD_demo[2975:159805] 2------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.835285+0800 GCD_demo[2975:159805] 2------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.835551+0800 GCD_demo[2975:159805] 2------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.836106+0800 GCD_demo[2975:159805] 3------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.836188+0800 GCD_demo[2975:159805] 3------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.836303+0800 GCD_demo[2975:159805] 3------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.836637+0800 GCD_demo[2975:159805] 3------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.836775+0800 GCD_demo[2975:159805] 3------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.836966+0800 GCD_demo[2975:159805] 3------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.837446+0800 GCD_demo[2975:159805] 3------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.838085+0800 GCD_demo[2975:159805] 3------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.838172+0800 GCD_demo[2975:159805] 3------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.838279+0800 GCD_demo[2975:159805] 3------<NSThread: 0x60400007f380>{number = 1, name = main}
2018-08-30 13:23:52.838639+0800 GCD_demo[2975:159890] end

放到子執行緒中執行，test6方法中的任務不用等待test6執行完再執行，所以不會死鎖。

iOS中主佇列的同/非同步執行

主佇列是主線中的一個序列佇列，通常我們重新整理UI都會回到主佇列。下面我們來看一下主佇列同步執行和非同步執行會產生什麼樣的效果。主佇列，非同步執行 //主佇列+非同步執行 //不會開啟新的執行緒，任務順序執行 -(void)test5{ NSLog(@"主佇列+非同步執

多執行緒中佇列和同/非同步執行問題

佇列分為並行佇列和序列佇列，執行方式分為同步執行和非同步執行，那麼組合一下就有四種方式，下面我會用GCD來驗證和總結一下各個組合的特性。併發佇列，同步執行 //併發佇列+同步執行 //不會開啟新執行緒，任務順序執行 -(void)test1{ NSLog(@"併發佇列+

vuex中action方法（非同步執行）

一.什麼是actions？背景：在mutation中我們講到，mutation中是存放處理資料的方法的集合，我們使用的時候需要commit。但是commit是同步函式，而且只能是同步執行。那我們想非同步操作怎麼辦？作用：在actions中提交mutation，並且可以包含任何的非同步

iOS開發-佇列和同步非同步執行

序列佇列，併發佇列，全域性佇列（併發），主佇列（序列）。執行的方法有：同步執行和非同步執行。提到多執行緒：pthread，NSThread，GCD，NSOperation 其中phtread是跨平臺的。 GCD和NSOperation都是常用的，後者是

關於GCD中序列佇列、併發佇列和同步執行、非同步執行的探討

Dispatch Queues Dispatch queue是一個物件，它可以接收任務，並將任務以先到先執行的順序來執行。Dispatch queue可以使併發的或序列的。併發任務會基於系統負載來合適地併發執行，序列佇列同一時間只執行單一任務。 GCD共有三種佇列型別： 1

node - 非同步執行，在佇列的底部,es5,es6公有繼承,node中util模組實現繼承和util模組的其他常用方法（很重要）

//非同步的，在當前佇列的底部 process.nextTick(function(){ console.log("1") }) //第二個佇列中 setImmediate(function(){ console.log("222") }) setTimeout(f

iOS多執行緒中，佇列和執行的排列組合結果分析

本文是對以往學習的多執行緒中知識點的一個整理。多執行緒中的佇列有：序列佇列，併發佇列，全域性佇列，主佇列。執行的方法有：同步執行和非同步執行。那麼兩兩一組合會有哪些注意事項呢？如果不是在董鉑然部落格園看到這邊文章請點選檢視原文提到多執行緒，也就是四種，pthread，NSthread，GCD

ios 中請求主執行緒重新整理UI

IOS中只有主執行緒才能立即重新整理UI。如果是通過偵聽非同步訊息，觸發回撥函式，或者呼叫非同步方法，請求重新整理UI，都會產生執行緒阻塞和延遲的問題。可以通過 if ([NSThread isMainThread]) {

主佇列-非同步執行;主佇列-同步執行(死鎖)

主佇列-同步執行死鎖問題,分享 //主佇列-非同步執行 //分析:在主執行緒,任務有序執行,當執行demo,就相當與在主佇列新增一個任務A,這個任務執行完NSLog的時候,又往對列中新增一個任務B;由於是非同步執行,所以任務A執行完之後,才去執行任務B(block裡面

ios多執行緒操作（六）—— GCD全域性佇列與主佇列

我們都應該清楚，同步任務有一個特性，只要一新增到佇列中就要馬上執行，主佇列中永遠就只要一條執行緒——主執行緒，此時主執行緒在等待著主佇列排程同步任務，而主佇列發現主執行緒上還有任務未執行完，就不會讓同步任務新增到主執行緒上，由此就造成了互相等待（主佇列在等待主執行緒執行完已有的任務，而主執行緒又在等

多執行緒中的佇列不一定需要執行緒安全

兩個執行緒，主執行緒中update update(){ 　　while(queue.count >0){ 　　　　//process.... 　　　　queue.pop() 　　} } 子執行緒中: queue.enqueue(data) 這樣做是沒有問

tensorflow中的佇列和執行緒

一、佇列 tensorflow中主要有FIFOQueue和RandomShuffleQueue兩種佇列，下面就詳細介紹這兩種佇列的使用方法和應用場景。 1、FIFOQueue FIFOQueue是先進先出佇列，主要是針對一些序列樣本。如：在使用迴圈神經網路的時候，需要處理語音、文字、

【小家java】Java中主執行緒（父執行緒）與子執行緒的通訊和聯絡

相關閱讀【小家java】java5新特性（簡述十大新特性）重要一躍【小家java】java6新特性（簡述十大新特性）雞肋升級【小家java】java7新特性（簡述八大新特性）不溫不火【小家java】java8新特性（簡述十大新特性）飽受讚譽【小家java】java9

Java執行緒中阻塞佇列

Java語言提供了java.util.concurrent包解決執行緒同步問題，concurrent包中的阻塞佇列BlockingQueue能夠很好地執行緒同步問題，介面BlockingQueue提供如下幾個執行緒同步方法儲存資料：　　offer(obj):向佇列BlockingQue

Android中使用非同步執行緒更新UI檢視的幾種方法

在Android中子執行緒是不能更新ui的。所以我們要通過其他方式來動態改變ui檢視， 1、runOnUiThreadactivity提供的一個輕量級更新ui的方法，在Fragment需要使用的時候要用getActivity.runOnUiThread開啟執行緒這種方法最簡單，方便更新一些不需要判斷的

iOS中保證執行緒安全的幾種方式與效能對比

一、前言前段時間看了幾個開源專案，發現他們保持執行緒同步的方式各不相同，有@synchronized、NSLock、dispatch_semaphore、NSCondition、pthread_mutex、OSSpinLock。後來網上查了一下，發現他們的實現機制各不相同，效能也各不一

iOS中的多執行緒

多執行緒的一些相關概念什麼是程序在系統中正在執行的一個應用程式。每個程序之間是獨立的，每個程序均執行在其專用而且受保護的記憶體空間內。什麼是執行緒一個程序要想執行任務，必須得有一個執行緒，而且每一個程序中至少有一個執行緒程序的所有任務都線上程中

c++ 執行緒併發、任務佇列、非同步任務封裝和分發 lambda與任務 boost

在開發C++程式時，一般在吞吐量、併發、實時性上有較高的要求。設計C++程式時，總結起來可以從如下幾點提高效率：併發非同步快取下面將我平常工作中遇到一些問題例舉一二，其設計思想無非以上三點。 1任務佇列 1.1 以生產者-消費者模型設計任務佇列

Java語言中的無鎖化執行緒安全佇列

在併發程式設計中，有時候需要使用執行緒安全的佇列。對於執行緒安全的佇列，有兩種實現方式：一種是阻塞（加鎖），一種是非阻塞（無鎖）。對於無鎖化執行緒安全佇列，實現要基於兩個方面：原子性操作和記憶體訪問控制。說的淺顯一些，就是在JDK中，需要用到Unsafe類中的CAS操作，結合volat

佇列在多執行緒中使用

1. 概述： 1.1 佇列簡介佇列是一種特殊的線性表，特殊之處在於它只允許在表的前端（front）進行刪除操作，而在表的後端（rear）進行插入操作，和棧一樣，佇列是一種操作受限制的線性表。進行插入操作的端稱為隊尾，進行刪除操作的端稱為隊頭。佇列

iOS中主佇列的同/非同步執行

主佇列，非同步執行

主佇列，同步執行

相關推薦