多線程下如何保證OkHttpClient的線程安全

多線程下的線程安全是很多同學(xué)都會(huì)遇到問題之一，雖然都說在客戶端使用多線程是不可取的，但客戶端本身是在一個(gè)多線程的環(huán)境下時(shí)，這個(gè)問題就不得不考慮了。

目前有以下幾個(gè)方面來解決這個(gè)問題

我們來看看都有什么：

• 單例模式：將 OkHttpClient 實(shí)例設(shè)計(jì)為單例，確保所有線程共享同一個(gè)實(shí)例。這樣可以避免多個(gè)線程創(chuàng)建多個(gè) OkHttpClient 實(shí)例，從而提高性能和資源利用率。
• 避免修改配置：在多線程環(huán)境中，盡量避免在運(yùn)行時(shí)修改 OkHttpClient 的配置。多個(gè)線程同時(shí)修改配置可能會(huì)導(dǎo)致競(jìng)爭(zhēng)條件和不一致的狀態(tài)。如果需要修改配置，建議在初始化階段完成，并在后續(xù)的使用中只讀取配置。
• 使用連接池：OkHttpClient 內(nèi)部使用連接池來管理網(wǎng)絡(luò)連接，確保連接的重用和資源的有效利用。默認(rèn)情況下，OkHttpClient 會(huì)自動(dòng)使用連接池。你可以通過設(shè)置連接池的參數(shù)來調(diào)整連接池的大小、保持時(shí)間等。
• 避免共享請(qǐng)求體：如果多個(gè)線程使用同一個(gè) RequestBody 對(duì)象發(fā)送請(qǐng)求，可能會(huì)導(dǎo)致不可預(yù)期的結(jié)果。每個(gè)請(qǐng)求應(yīng)該有自己的 RequestBody 對(duì)象，以避免并發(fā)訪問的問題。
• 避免共享 Response 對(duì)象：OkHttp 的 Response 對(duì)象是非線程安全的，因此應(yīng)避免多個(gè)線程共享同一個(gè) Response 對(duì)象。每個(gè)線程應(yīng)該獨(dú)立處理自己的 Response 對(duì)象。
• 使用 OkHttpClient 的新實(shí)例：如果你需要在不同的線程中獨(dú)立使用 OkHttpClient，可以為每個(gè)線程創(chuàng)建一個(gè)新的 OkHttpClient 實(shí)例。這樣可以避免線程之間的狀態(tài)混亂和資源沖突。

這幾個(gè)方案中單例模式的 OkHttpClient 實(shí)例是效率最高的方案之一。

因?yàn)閱卫Ｊ酱_保所有線程共享同一個(gè) OkHttpClient 實(shí)例，避免了多個(gè)線程創(chuàng)建多個(gè)實(shí)例的開銷和資源浪費(fèi)。

but，我們說的前提是多線程下，那么并發(fā)訪問可能帶來的競(jìng)爭(zhēng)條件和同步問題是單例模式下無法避免的。

除了單例模式之外，其他方案的效率取決于具體的使用場(chǎng)景和需求。今天我們先來說說如何使用 OkHttpClient 的新實(shí)例來避免多線程下的線程安全。

使用 OkHttpClient 的新實(shí)例這個(gè)方案的核心在于我們?yōu)槊恳粋€(gè)新的線程都創(chuàng)建了OkHttpClient客戶端示例，以此來避免線程共享資源和相互競(jìng)爭(zhēng)。

為了實(shí)現(xiàn)這個(gè)目標(biāo)，我們就需要2個(gè)至關(guān)重要的對(duì)象：

• 1、線程唯一標(biāo)識(shí)
• 2、可以批量創(chuàng)造OkHttpClient的工廠

首先我們?cè)谖覀兊姆椒ㄖ锌梢允褂靡韵麓a來獲取當(dāng)前使用該方法的線程ID：

long threadId = Thread.currentThread().getId();

有了線程ID，下一步就是如何使用它。我們?cè)谑褂盟?，需要建立OkHttpClient的工廠

如下：

public class OkHttpClientFactory {

    private static final ThreadLocal<ConcurrentHashMap<Long, OkHttpClient>> clientMapThreadLocal = new ThreadLocal<>();

    public OkHttpClient getInstance(long threadId) {
        ConcurrentHashMap<Long, OkHttpClient> threadMap = clientMapThreadLocal.get();
        if (threadMap == null) {
            threadMap = new ConcurrentHashMap<>();
            clientMapThreadLocal.set(threadMap);
        }
        OkHttpClient value = threadMap.computeIfAbsent(threadId, k -> new OkHttpClient().newBuilder()
                .connectTimeout(10, TimeUnit.SECONDS) // 設(shè)置連接超時(shí)時(shí)間為10秒
                .readTimeout(30, TimeUnit.SECONDS) //讀取超時(shí)時(shí)間設(shè)置為30秒
                .build());
        if (threadMap.size() == 1) {
            // 如果這是唯一剩下的（threadId -> value），則刪除 ThreadLocal
            clientMapThreadLocal.remove();
        }
        return value;
    }
}

我們簡(jiǎn)單的解釋一下這段代碼

1、clientMapThreadLocal：這是一個(gè) ThreadLocal 對(duì)象，用于存儲(chǔ)每個(gè)線程對(duì)應(yīng)的 ConcurrentHashMap 實(shí)例。ThreadLocal 可以確保每個(gè)線程都有自己獨(dú)立的 ConcurrentHashMap 實(shí)例。

2、getInstance() 方法：這是獲取 OkHttpClient 實(shí)例的方法。它接受一個(gè) threadId 參數(shù)作為線程的唯一標(biāo)識(shí)，用于區(qū)分不同的線程。

3、threadMap：首先，代碼從 clientMapThreadLocal 中獲取當(dāng)前線程的 ConcurrentHashMap 實(shí)例。如果當(dāng)前線程尚未在 clientMapThreadLocal 中擁有對(duì)應(yīng)的實(shí)例，它會(huì)創(chuàng)建一個(gè)新的 ConcurrentHashMap 并將其設(shè)置到 clientMapThreadLocal 中。

4、threadMap.computeIfAbsent()：接下來，通過 computeIfAbsent() 方法，根據(jù) threadId 獲取對(duì)應(yīng)的 OkHttpClient 實(shí)例。如果 threadId 在 threadMap 中不存在，則使用 new OkHttpClient().newBuilder() 創(chuàng)建一個(gè)新的 OkHttpClient 實(shí)例，并設(shè)置一些默認(rèn)的連接和讀取超時(shí)時(shí)間。

5、threadMap.size() == 1：如果 threadMap 中只剩下一個(gè)元素（即當(dāng)前線程的 threadId 對(duì)應(yīng)的 OkHttpClient 實(shí)例），則刪除 clientMapThreadLocal 中的 threadMap。這是為了避免在沒有其他線程需要使用 OkHttpClient 的情況下，保持對(duì) threadMap 的引用。

到了這里相信有很多同學(xué)已經(jīng)明白了，這個(gè)方案的核心邏輯就是想辦法讓每個(gè)線程都擁有自己的實(shí)例。

最后我們可以在任何方法中使用以下代碼來獲取安全，且支持高并發(fā)的OkHttpClient ：

  long threadId = Thread.currentThread().getId();
  OkHttpClientFactory factory = new OkHttpClientFactory();
  OkHttpClient client =  factory.getInstance(threadId);

但需要注意的，這個(gè)方案并非沒有缺點(diǎn)。

它對(duì)與計(jì)算機(jī)資源的要求相比于其它的方案要搞得多…

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論