2. 程式人生 > >libevent原始碼分析之多執行緒準備工作

libevent原始碼分析之多執行緒準備工作

阿新 • • 發佈：2019-01-01
libevent中是預設不開啟多執行緒的,也就沒有什麼鎖, 條件變數等的說法了
我們可以使用evthread_use_pthreads()開啟linux下的pthread

#ifdef WIN32
int evthread_use_windows_threads(void);
#define EVTHREAD_USE_WINDOWS_THREADS_IMPLEMENTED
#endif
#ifdef _EVENT_HAVE_PTHREADS
int evthread_use_pthreads(void);
#define EVTHREAD_USE_PTHREADS_IMPLEMENTED
#endif

或者使用evthread_set_lock_callbacks定製屬於自己的多執行緒, 鎖, 條件變數等

libevent是如何封裝多執行緒的呢, 還需要從下面這個結構體說起:

這是對某種執行緒的鎖的一些操作封裝: 


struct evthread_lock_callbacks {
    /** The current version of the locking API.  Set this to
     * EVTHREAD_LOCK_API_VERSION */
        /**/
    int lock_api_version;
    /** Which kinds of locks does this version of the locking API
     * support?  A bitfield of EVTHREAD_LOCKTYPE_RECURSIVE and
     * EVTHREAD_LOCKTYPE_READWRITE.
     *
     * (Note that RECURSIVE locks are currently mandatory, and
     * READWRITE locks are not currently used.)
     **/
    unsigned supported_locktypes;

        //初始化鎖
    void *(*alloc)(unsigned locktype);

        //釋放鎖
    void (*free)(void *lock, unsigned locktype);

    int (*lock)(unsigned mode, void *lock);

    int (*unlock)(unsigned mode, void *lock);
};

根據官方給出的文件, 支援的鎖型別有：
普通的非遞迴鎖                                               0
遞迴鎖, 即本執行緒可以多次對某鎖進行lock而不會進入死鎖          EVTHREAD_LOCKTYPE_RECURSIVE
讀寫鎖                                   EVTHREAD_LOCKTYPE_READWRITE

支援的鎖mode有:
EVTHREAD_READ , EVTHREAD_WRITE ,  EVTHREAD_TRY


以上是封裝的執行緒鎖, 下面是封裝的執行緒條件變數：
struct evthread_condition_callbacks {
    int condition_api_version;

    void *(*alloc_condition)(unsigned condtype);

    void (*free_condition)(void *cond);

    int (*signal_condition)(void *cond, int broadcast);

    int (*wait_condition)(void *cond, void *lock,
        const struct timeval *timeout);
};

因為對於條件變數的包裝類似, 所以這裡略過

如何與libeven相結合的呢?

文章頂部提到, 我們可以使用evthread_use_pthreads來開啟linux下的pthread：
int
evthread_use_pthreads(void)
{
    struct evthread_lock_callbacks cbs = {
        EVTHREAD_LOCK_API_VERSION,
        EVTHREAD_LOCKTYPE_RECURSIVE,
        evthread_posix_lock_alloc,    
        evthread_posix_lock_free,
        evthread_posix_lock,
        evthread_posix_unlock
    };
    struct evthread_condition_callbacks cond_cbs = {
        EVTHREAD_CONDITION_API_VERSION,
        evthread_posix_cond_alloc,
        evthread_posix_cond_free,
        evthread_posix_cond_signal,
        evthread_posix_cond_wait
    };
    /* Set ourselves up to get recursive locks. */
        //以下為初始化遞迴鎖的屬性，attr_recursive是全域性變數, 該屬性物件是在初始化一個鎖的時候使用的
        //雖然我們的預設鎖的名字叫EVTHREAD_LOCKTYPE_RECURSIVE，但真正讓它稱為遞迴鎖還是要靠這個屬性而不是單純的名字就行...
    if (pthread_mutexattr_init(&attr_recursive))
        return -1;
        //為該屬性新增遞迴鎖的遞迴屬性
    if (pthread_mutexattr_settype(&attr_recursive, PTHREAD_MUTEX_RECURSIVE))
        return -1;

        //設定整個event_base將會使用的執行緒鎖、條件變數、 以及如何獲取執行緒自身的執行緒ID
    evthread_set_lock_callbacks(&cbs);
    evthread_set_condition_callbacks(&cond_cbs);
    evthread_set_id_callback(evthread_posix_get_id);
    return 0;
}

關於這裡面的函式, 要提一下的是下面的函式:
static void *
evthread_posix_lock_alloc(unsigned locktype)
{
    pthread_mutexattr_t *attr = NULL;
    pthread_mutex_t *lock = mm_malloc(sizeof(pthread_mutex_t));
    if (!lock)
        return NULL;
    //從這裡可以看出, 如果我們需要遞迴鎖, 那麼就會用到那個全域性變數, 否則就是普通的非遞迴鎖
        //還可以看出來的是, 並沒有支援讀寫鎖
    if (locktype & EVTHREAD_LOCKTYPE_RECURSIVE)        
        attr = &attr_recursive;
    if (pthread_mutex_init(lock, attr)) {
        mm_free(lock);
        return NULL;
    }
    return lock;
}

static int
evthread_posix_cond_signal(void *_cond, int broadcast)
{
    pthread_cond_t *cond = _cond;
    int r;
    if (broadcast)                //可見, 如果broadcast不為0, 那麼就會喚醒不止一個執行緒
        r = pthread_cond_broadcast(cond);
    else
        r = pthread_cond_signal(cond);
    return r ? -1 : 0;
}


好了,看到這裡, 想必對libevent對執行緒的支援有所瞭解了,只是簡單的在我們平時使用的基礎上進行一些封裝, 理解起來並不困難
還有要注意的是, 設定libevent支援執行緒必須在最開始就宣告好！與自己設定記憶體分配函式、日誌記錄函式類似, 不能半途設定的！

debug鎖

除了普通的系統支援的鎖之外, libevent還定製了一種特有的鎖

該鎖支援對鎖操作的幾個檢測,如下, 看過後還會做總結：
1、某執行緒可能解鎖自己並不持有的鎖
2、在沒有解鎖之前，想要鎖住一個非遞迴的鎖

如何開啟呢, 可以在使用evthread_use_pthreads開啟執行緒後, 再呼叫evthread_enable_lock_debugging就可以開啟debug鎖了
void
evthread_enable_lock_debuging(void)
{
    struct evthread_lock_callbacks cbs = {
        EVTHREAD_LOCK_API_VERSION,
        EVTHREAD_LOCKTYPE_RECURSIVE,
        debug_lock_alloc,
        debug_lock_free,
        debug_lock_lock,
        debug_lock_unlock
    };

        //是否已經宣告過該debug鎖了
    if (_evthread_lock_debugging_enabled)
        return;

        //全域性變數_evthread_lock_fns是在evthread_use_pthreads中呼叫evthread_set_lock_callbacks為其賦值的
        //現在用_original_lock_fns變數來儲存它
    memcpy(&_original_lock_fns, &_evthread_lock_fns,
        sizeof(struct evthread_lock_callbacks));

        //此刻的_evthread_lock_fns成為了debug鎖
    memcpy(&_evthread_lock_fns, &cbs,
        sizeof(struct evthread_lock_callbacks));

    memcpy(&_original_cond_fns, &_evthread_cond_fns,
        sizeof(struct evthread_condition_callbacks));

        //這裡只是修改了條件變數裡的一個函式, 這是因為只有wait函式才用到鎖...
    _evthread_cond_fns.wait_condition = debug_cond_wait;
    _evthread_lock_debugging_enabled = 1;

    /* XXX return value should get checked. */
    event_global_setup_locks_(0);
}


也就是說, 現在所有的鎖相關到操作都被替換為debug鎖的操作了, 之前在evthread_set_lock_callbacks設定的雖然被取代但也都被保留了下來
於是我們現在看看debug鎖的具體操作：

struct debug_lock {
    unsigned locktype;
    unsigned long held_by;
    /* XXXX if we ever use read-write locks, we will need a separate
     * lock to protect count. */
    int count;
    void *lock;
};
static void *
debug_lock_alloc(unsigned locktype)
{
    struct debug_lock *result = mm_malloc(sizeof(struct debug_lock));
    if (!result)
        return NULL;
        //如果我們是在開啟了執行緒之後開啟debug鎖的, 那麼我們會利用該鎖的alloc函式為debug鎖生成一個物件, 要注意的是, 是遞迴鎖
    if (_original_lock_fns.alloc) {
        if (!(result->lock = _original_lock_fns.alloc(
                locktype|EVTHREAD_LOCKTYPE_RECURSIVE))) {
            mm_free(result);
            return NULL;
        }
    } else {
        result->lock = NULL;
    }
    result->locktype = locktype;
    result->count = 0;
    result->held_by = 0;
    return result;
}



從上面我們可以知道, 分配、釋放debug鎖和分配、釋放系統鎖並沒有太大差別.
差別主要在於debug的主要職責上, 即在加鎖和解鎖時進行特別的判定
如下：

//此時,我們需要上鎖
static int
debug_lock_lock(unsigned mode, void *lock_)
{
    struct debug_lock *lock = lock_;
    int res = 0;
        //此鎖的locktype就是建立時候自己定義的,外加一個遞迴屬性 , 如果此鎖是讀寫鎖
        //這裡的判斷是, 如果是讀寫鎖, 至少有個讀鎖或寫鎖的屬性
    if (lock->locktype & EVTHREAD_LOCKTYPE_READWRITE)
        EVUTIL_ASSERT(mode & (EVTHREAD_READ|EVTHREAD_WRITE));
    else
        //既然不是讀寫鎖, 那就不應該有讀鎖或寫鎖的屬性
        EVUTIL_ASSERT((mode & (EVTHREAD_READ|EVTHREAD_WRITE)) == 0);

        //如果被debug封裝的鎖具有鎖的屬性, 如果沒有,那就表示這之前沒有呼叫evthread_use_pthreads等開啟多執行緒, 也表示lock變數中的lock成員為空
    if (_original_lock_fns.lock)
        res = _original_lock_fns.lock(mode, lock->lock);   //要知道的是, lock成功返回0

        //進入這個if有兩個條件, 一個是這之前沒有呼叫evthread_use_pthreads等, 二是成功鎖住此鎖了
    if (!res) {
        evthread_debug_lock_mark_locked(mode, lock);
    }
    return res;
}

static void
evthread_debug_lock_mark_locked(unsigned mode, struct debug_lock *lock)
{
    ++lock->count;            //此變數初始值為0
        //如果沒有遞迴這個屬性, 即非遞迴鎖, count只能為1. 只是若一個非遞迴的鎖是正常的(是沒bug的？),那麼肯定會在呼叫_original_lock_fns.lock時形成死鎖而不會到這一步...
    if (!(lock->locktype & EVTHREAD_LOCKTYPE_RECURSIVE))
        EVUTIL_ASSERT(lock->count == 1);
    if (_evthread_id_fn) {
                //得到當前執行緒的執行緒ID
        unsigned long me;
        me = _evthread_id_fn();
                //如果count大於1了,說明到了遞迴鎖的特性了, 必須是本執行緒先前就擁有的這把鎖的所有權
        if (lock->count > 1)
            EVUTIL_ASSERT(lock->held_by == me);
        lock->held_by = me;
    }
}



看了加鎖的實現, 肯定是迫不及待的去看解鎖的實現了：

static int
debug_lock_unlock(unsigned mode, void *lock_)
{
    struct debug_lock *lock = lock_;
    int res = 0;
    evthread_debug_lock_mark_unlocked(mode, lock);
    if (_original_lock_fns.unlock)
        res = _original_lock_fns.unlock(mode, lock->lock);
    return res;
}
static void
evthread_debug_lock_mark_unlocked(unsigned mode, struct debug_lock *lock)
{
    if (lock->locktype & EVTHREAD_LOCKTYPE_READWRITE)
        EVUTIL_ASSERT(mode & (EVTHREAD_READ|EVTHREAD_WRITE));
    else
        EVUTIL_ASSERT((mode & (EVTHREAD_READ|EVTHREAD_WRITE)) == 0);
    if (_evthread_id_fn) {
                //如果持有鎖的執行緒不是我,那麼就出錯了
        EVUTIL_ASSERT(lock->held_by == _evthread_id_fn());
                //如果此鎖count為1,那麼解鎖後就不歸任何執行緒所有了
        if (lock->count == 1)
            lock->held_by = 0;
    }
    --lock->count;
        //如果之前沒有鎖過這個鎖, 那麼無需解...
    EVUTIL_ASSERT(lock->count >= 0);
}


綜上,再來總結一下debug鎖解決了哪些不該出現的問題呢？
1、首先我們知道, 對於一個讀寫鎖(在呼叫alloc申請的時候表明的意圖),如果在給鎖加鎖的時候沒有指定任何EVTHREAD_READ或寫的加鎖模式,那麼肯定是錯誤的（解鎖亦然）
2、（可能,這一條不確定...）對於一個非遞迴鎖卻在一個執行緒中呼叫lock不止一次,可能會報錯(可能直接死鎖了)
3、遞迴四隻能在一個執行緒中鎖幾次
4、當前鎖是鎖住的,但加鎖的不是我, 但我要去解鎖,就出錯
5、沒有加過鎖, 卻還要解鎖


設定libevent要用的執行緒相關工具

認識了debug鎖, 接下來我們更加深入的探討一下evthread_set_lock_callbacks函式：

int
evthread_set_lock_callbacks(const struct evthread_lock_callbacks *cbs)
{
        //_evthread_lock_debugging_enabled標誌為全域性變數,初始為0, 為是否開啟debug鎖, 不過開啟debug鎖一般在開啟執行緒之後的
        //然而呼叫此函式evthread_set_lock_callbacks
    struct evthread_lock_callbacks *target =
        _evthread_lock_debugging_enabled
        ? &_original_lock_fns : &_evthread_lock_fns;

    if (!cbs) {
                //加入引數為NULL， 那麼可以取消鎖的實現, 只是警告中說這並不一定起作用
        if (target->alloc)
            event_warnx("Trying to disable lock functions after "
                "they have been set up will probaby not work.");
        memset(target, 0, sizeof(_evthread_lock_fns));
        return 0;
    }
        //這步操作可能並不是在我們之前提到的整個libevent的最前面發生的,情理之中也是不允許中途改鎖的
    if (target->alloc) {
        /* Uh oh; we already had locking callbacks set up.*/
        if (target->lock_api_version == cbs->lock_api_version &&
            target->supported_locktypes == cbs->supported_locktypes &&
            target->alloc == cbs->alloc &&
            target->free == cbs->free &&
            target->lock == cbs->lock &&
            target->unlock == cbs->unlock) {
            /* no change -- allow this. */
            return 0;
        }
        event_warnx("Can't change lock callbacks once they have been "
            "initialized.");
        return -1;
    }

        //必須支援這裡的所有操作,否則無法接受
    if (cbs->alloc && cbs->free && cbs->lock && cbs->unlock) {
        memcpy(target, cbs, sizeof(_evthread_lock_fns));
        return event_global_setup_locks_(1);
    } else {
        return -1;
    }
}



看到這裡,是不是覺得就不能修改鎖的相關函數了呢, 其實是可以的, 首先我們第一次呼叫傳入NULL引數, 第二次呼叫傳入新的操作函式結構體, 可能就可以了
但是, 這樣做是存在問題的.

瞭解了鎖的大部分實現後, 我們來看看是libevent是如何應用他們的
經常見到的就是這兩個了：
EVBASE_ACQUIRE_LOCK(ev->ev_base, th_base_lock);
和
EVBASE_RELEASE_LOCK(ev->ev_base, th_base_lock);
第一個引數為base , 第二個為鎖物件

某個鎖定然是與某個base相關的,於是我們第一事件找到event_base：
struct event_base {

        ... ...

#ifndef _EVENT_DISABLE_THREAD_SUPPORT
    /* threading support */
    /** The thread currently running the event_loop for this base */
        //主執行緒ID
    unsigned long th_owner_id;
    /** A lock to prevent conflicting accesses to this event_base */
        //訪問base中元素用的lock, 比如有時候需要新增一些事件等
    void *th_base_lock;
        
        ... ...

    /** A condition that gets signalled when we're done processing an
     * event with waiters on it. */
    void *current_event_cond;
    /** Number of threads blocking on current_event_cond. */
    int current_event_waiters;
#endif
        
        ... ...

};

接下來看看巨集的相關實現：
#define EVBASE_ACQUIRE_LOCK(base, lockvar) do {                         \
                EVLOCK_LOCK((base)->lockvar, 0);
        } while (0)

#define EVLOCK_LOCK(lockvar,mode)                                       \
        do {                                                            \
                     //如果這個鎖是存在的, 就呼叫lock函式來鎖
                if (lockvar)                                            \
                        _evthread_lock_fns.lock(mode, lockvar);         \
        } while (0)

#define EVBASE_RELEASE_LOCK(base, lockvar) do {                         \
                EVLOCK_UNLOCK((base)->lockvar, 0);                      \
        } while (0)

#define EVLOCK_UNLOCK(lockvar,mode)                                     \
        do {                                                            \
                if (lockvar)                                            \
                        _evthread_lock_fns.unlock(mode, lockvar);       \
        } while (0)


這個lockvar我們看到在event_base中有定義, 憑什麼說lockvar存在, 對應的鎖函式就存在呢？
我們就來看看是如何初始化這個鎖的：
struct event_base *
event_base_new_with_config(const struct event_config *cfg)
{

        ... ...

    /* prepare for threading */

#ifndef _EVENT_DISABLE_THREAD_SUPPORT
    if (EVTHREAD_LOCKING_ENABLED() &&
              //如果沒有事先宣告不需要鎖
        (!cfg || !(cfg->flags & EVENT_BASE_FLAG_NOLOCK))) {
        int r;
 
                //此鎖被宣告為遞迴鎖
        EVTHREAD_ALLOC_LOCK(base->th_base_lock,
            EVTHREAD_LOCKTYPE_RECURSIVE);
        base->defer_queue.lock = base->th_base_lock;
        EVTHREAD_ALLOC_COND(base->current_event_cond);
        r = evthread_make_base_notifiable(base);
        if (r<0) {
            event_warnx("%s: Unable to make base notifiable.", __func__);
            event_base_free(base);
            return NULL;
        }
    }
#endif

        ... ...

}



此鎖也是普通的利用鎖的alloc函式構造的,所以並不是說 lockvar存在, 對應的鎖函式就存在, 而是說如果lockvar不存在, 那麼對應鎖函式也不會存在, 也就不會去呼叫到它
也就避免了這個可能的錯誤
不過,之前我們提到, 在宣告使用執行緒後, base的初始化就會成功初始化base->th_base_lock, 此時我們可以通過給evthread_set_lock_callbacks傳入NULL引數, 現在就算lcokvar存在,我們也無法證明其對應的鎖函式是存在的了！像現在的情況, 傳入NULL後, 鎖函式為空, 再次執行到鎖的巨集, 就會出錯了。
所以不提倡在執行後修改鎖的操作函式。

相關推薦

libevent原始碼分析之多執行緒準備工作

libevent中是預設不開啟多執行緒的,也就沒有什麼鎖, 條件變數等的說法了 我們可以使用evthread_use_pthreads()開啟linux下的pthread#ifdef WIN32 int evthread_use_windows_threads(void);

Netty原始碼分析之Reactor執行緒模型

一、背景  最近在研究netty的原始碼，今天發表一篇關於netty的執行緒框架--Reactor執行緒模型，作為最近研究成果。如果有還不瞭解Reactor模型請自行百度，網上有很多關於Reactor模式。  研究netty的時候，先看了下《netty權威指南》，裡面講解不

Spring IOC原始碼分析之-重新整理前的準備工作

目錄 ClassPathXmlApplicationContext的註冊方式 載入父子容器 配置路徑解析 容器重新整理 重新整理容器之重新整理預處理

Android多執行緒之（一）View.post()原始碼分析——在子執行緒中更新UI

       提起View.post()，相信不少童鞋一點都不陌生，它用得最多的有兩個功能，使用簡便而且實用：        1）在子執行緒中更新UI。從子執行緒中切換到主執行緒更新UI，不需要額外new一個Handler例項來實

JAVA之多執行緒概念及其幾種實現方法優劣分析

1. 多執行緒 程式：指令集，靜態的概念 程序：作業系統調動程式，是程式的一次動態執行過程，動態的概念 執行緒：在程序內的多條執行路徑 Ps：單核的話程序都是虛擬模擬出來的，多核處理器才可以執行真正的多執行緒 單核通過CPU排程時間片實現虛擬模擬的多執行緒，比如執行main函式和GC在底層就是多執行

cocos2d-x遊戲引擎核心之多執行緒分析及注意事項

一、多執行緒原理 （1）單執行緒的尷尬 　　重新回顧下 Cocos2d-x 的並行機制。引擎內部實現了一個龐大的主迴圈，在每幀之間更新各個精靈的狀態、執行動作、呼叫定時函式等，這些操作之間可以保證嚴格獨立，互不干擾。不得不說，這是一個非常巧妙的機制，它

HashMap原始碼解析、jdk7和8之後的區別、相關問題分析（多執行緒擴容帶來的死迴圈）

# 一、概覽 ```java HashMap map = new HashMap(); ``` 這個語句執行起來，在 jdk1.8 之前，會建立一個長度是 16 的 `Entry[]` 陣列，叫 `table`，用來儲存鍵值對。 在 jdk 1.8 後，不在這裡建立陣列了，而是在第一次 `pu

Python爬蟲之多執行緒，多程序

前言 我們之前寫的爬蟲都是單個執行緒的？這怎麼夠？一旦一個地方卡到不動了，那不就永遠等待下去了？為此我們可以使用多執行緒或者多程序來處理。 首先宣告一點！ 多執行緒和多程序是不一樣的！一個是 thread 庫，一個是 multiprocessing 庫。而多執行緒 thread 在 Pytho

java面試/筆試題目之多執行緒及鎖 (持續更新中)

前言：這一模組可以參照徐劉根大佬的部落格。 一.執行緒和程序的概念、並行和併發的概念 1.程序：是計算機中的程式關於某資料集合上的一次執行活動，是系統 進行資源分配和排程的基本單位，是作業系統結構的基礎。程式是指令、資料及其組織形式的描述，程序是程式的實體。 2.執行緒：是程式執行流的

併發程式設計之多執行緒執行緒安全

什麼是執行緒安全？ 為什麼有執行緒安全問題？ 當多個執行緒同時共享，同一個全域性變數或靜態變數，做寫的操作時，可能會發生資料衝突問題，也就是執行緒安全問題。但是做讀操作是不會發生資料衝突問題。 案例: 需求現在有100張火車票，有兩個視窗同時搶火車票，請使用多執行緒模擬搶票效果。 p

併發程式設計之多執行緒基礎

執行緒與程序區別 每個正在系統上執行的程式都是一個程序。每個程序包含一到多個執行緒。執行緒是一組指令的集合，或者是程式的特殊段，它可以在程式裡獨立執行。也可以把它理解為程式碼執行的上下文。所以執行緒基本上是輕量級的程序，它負責在單個程式裡執行多工。通常由作業系統負責多個執行緒的排程和執行。

2018-08-28微服務筆記（一）之多執行緒

1.多執行緒 1.1 程序與執行緒 (1)程序：正在執行的程式，是執行緒的集合。主執行緒決定程式碼的執行順序。 (2)執行緒：正在獨立執行的一條執行路徑。 (3)多執行緒：為了提高程式的效率。 1.2 四種方式建立執行緒 (1)繼承Thread類 (2)實現Runnable介面

.NET基礎之多執行緒開發基礎

轉自：http://www.cnblogs.com/edisonchou/p/4848131.html   多執行緒開發基礎  Index :  （1）型別語法、記憶體管理和垃圾回收基礎  （2）面向物件的實現和異常的處理基礎

面試題之——多執行緒併發面試題

1) 什麼是執行緒？ 　　執行緒是作業系統能夠進行運算排程的最小單位，它被包含在程序之中，是程序中的實際運作單位。程式設計師可以通過它進行多處理器程式設計，你可以使用多執行緒對運算密集型任務提速。比如，如果一個執行緒完成一個任務要100毫秒，那麼用十個執行緒完成改任務只需10毫秒。Java在語言層面對多執行

面試題之——多執行緒詳解

多執行緒作為Java中很重要的一個知識點，在此還是有必要總結一下的。 一.執行緒的生命週期及五種基本狀態 關於Java中執行緒的生命週期，首先看一下下面這張較為經典的圖： 上圖中基本上囊括了Java中多執行緒各重要知識點。掌握了上圖中的各知識點，Java中的多執行緒也就基本上掌握了。主

JAVA複習之多執行緒

java中多執行緒同步是什麼？ 在多執行緒程式下，同步能控制對共享資源的訪問。如果沒有同步，當一個java縣城在修改一個共享變數時，另外一個執行緒正在使用或者更新同一個變數，這樣容易導致程式出現錯誤。 解釋實現多執行緒的幾種方法？區別是什麼？ Java執行緒可以實現Runnable介面或

Java基礎之多執行緒及併發庫

實際上關於多執行緒的基礎知識，前面自己已經總結過一部分，但是每一個階段對於同樣知識點的學習側重點是不一樣的，前面的Java基礎總結八之多執行緒（一）和 Java基礎總結九之多執行緒（二）是對JDK5以前多執行緒相關基礎知識的一個簡單總結，今天本文將偏重於JDK5提供的併發庫進行學習總結。 首先，

Android開發之多執行緒的操作方式Thread,TimerTask,AsyncTask

雨鬆MOMO原創文章如轉載，請註明：轉載至我的獨立域名部落格雨鬆MOMO程式研究院，原文地址:http://www.xuanyusong.com/archives/344 Android研究院之遊戲開發多執行緒（十六）   遊戲開發與軟體開發多執行緒的重要性  &

Spring 之多執行緒

    Spring 通過任務執行器 TaskExecutor  來實現多執行緒和併發程式設計, 使用 ThreaPoolTaskExector  可實現一個基於執行緒池的 TaskExecutor. 而實際開發任務一般非阻礙的,即非同步.所以我們要在配置

Python併發程式設計之多執行緒使用

目錄 一 開啟執行緒的兩種方式 二 在一個程序下開啟多個執行緒與在一個程序下開啟多個子程序的區別 三 練習 四 執行緒相關的其他方法 五 守護執行緒 六 Python GIL(Global Interpreter Lock) 七 同步鎖 八 死鎖現象