下面文章進行著重分析下什么是Python線程，以及為什么要使用Python線程？對于Python線程的功能特點進行近一步的說明介紹，好了，就隨我進入Python線程的世界吧。

比如考慮一個最簡單的情形，在某種情況下，每個線程都需要訪問線程狀態對象中所保存的thread_id信息，顯然，線程A獲得的應該是A的thread_id，線程B亦然。倘若線程A獲得的是B的thread_id，那就壞菜了。這就意味著Python線程內部必須有一套機制，這套機制與操作系統管理進程的機制非常類似。

我們知道，在操作系統從進程A切換到進程B時，首先會保存進程A的上下文環境，再進行切換；當從進程B切換回進程A時，又會恢復進程A的上下文環境，這樣就保證了進程A始終是在屬于自己的上下文環境中運行。

這里的線程狀態對象就等同于進程的上下文，Python同樣會有一套存儲、恢復線程狀態對象的機制。同時，在Python內部，維護著一個全局變量：PyThreadState * _PyThread- State_Current。當前活動線程所對應的線程狀態對象就保存在這個變量里，當Python調度線程時。會將被激活的線程所對應的線程狀態對象賦給_PyThreadState_Current，使其始終保存著活動線程的狀態對象。#t#

這就引出了這樣的一個問題：Python如何在調度進程時，獲得被激活線程對應的狀態對象？Python內部會通過一個單向鏈表來管理所有的Python線程的狀態對象。當需要尋找一個線程對應的狀態對象時，就遍歷這個鏈表，搜索其對應的狀態對象。在此后的描述中，我們將這個鏈表稱為“狀態對象鏈表”。

下面我們來看一看實現這個機制的關鍵數據結構。PyThread_create_key將創建一個新的key。注意，這里的key都是一個整數。而且，當PyThread_create_key***次被調用時（在_PyGILState_Init中的調用正是***次調用），會通過PyThread_allcate_lock創建一個keymutex。

根據我們前面的分析，這個keymutex實際上和GIL一樣，都是一個PNRMUTEX結構體，而在這個結構體中，維護著一個Win32下的Event內核對象。這個keymutex的功能就是用來互斥對狀態對象鏈表的訪問。在_PyGILState_Init中，創建的新key被Python維護的全局變量autoTLSkey接收，其中的TLS是Thread Local Store的縮寫。

這個autoTLSkey將用作Python線程保存所有線程的狀態對象的一個參數，即是圖15-6中的key值。也就是說，狀態對象列表中所有key結構體中的key值都會是autoTLSkey。哎，那位看官說了，你看PyThread_create_key返回的是nkeys的遞增后的值啊，就是說每create一次，得到的結果都是不同的。

怎么能說所有的key都是一樣的呢？事實上，在整個Python的源碼中，PyThread_create_key只在_PyGILState_Init中被調用了，而這個_PyGILState_Init只會在Python運行時環境初始化時調用一次。

那么如何區分哪個線程對應哪個狀態對象呢，別忘了，我們還有線程id呢。圖15-6中的id存儲的正是各個線程的id，根據這個id，顯然可以區分不同的線程了。那么圖中的key看上去就有點多此一舉了，實際上，圖15-6中所示的鏈表結構并非是純的狀態對象鏈表。

在一個key結構體的value域存儲的不是線程的狀態對象，而是與線程相關的其他對象時，這個key值就有意義了。假如我們將一種狀態對象設為S，而另一種對象設為O，在圖15-6所示的鏈表中，存在著兩個與某個線程A相關的key結構體。

顯然，對于這兩個key結構體，id域是完全一致的，那么當我們需要從這個鏈表中取出對象O，而并非S時，該用什么來區分O和S呢？正是這個key值。所以實際上在Python中，與每個線程相關的對象可能有多種，而每一種對象都會對應一個key值，這個key值將會被所有的線程在存儲這種對象時共享。

對于我們這里關注的線程狀態對象，其key值就是autoTLSkey。同樣，由于我們這里僅僅關注Python線程機制，所以我們在后面的描述中還是將圖15-6中的鏈表稱為線程狀態對象鏈表。