資訊專欄INFORMATION COLUMN
在使用Spring Boot開發(fā)過程中，并發(fā)concurrency問題不可避免。很多開發(fā)者存在這樣的誤區(qū)，使用Servlets為每個(gè)請(qǐng)求分配一個(gè)新的線程進(jìn)行處理就不再需要并發(fā)處理了。我將在這篇文章中介紹如何在Spring Boot中處理并發(fā)并且如何避免一些問題。
有以下幾點(diǎn)特別值得注意：
最大線程數(shù)：這是為處理應(yīng)用程序的請(qǐng)求而分配的最大線程數(shù)。
共享資源：調(diào)用共享資源如數(shù)據(jù)庫
異步方法調(diào)用：這些方法調(diào)用將會(huì)釋放線程資源
內(nèi)部共享資源：內(nèi)部資源調(diào)用如緩存、共享應(yīng)用程序狀態(tài)
接下來我們逐一介紹如何處理這些場景
首先我們必須限制應(yīng)用程序的線程數(shù)量。如果使用默認(rèn)內(nèi)嵌的Tomcat Server，我們可以通過server.tomcat.max-threads變量修改線程數(shù)量限制。默認(rèn)為200。我們可以通過修改此配置以更合理利用硬件資源。
調(diào)用數(shù)據(jù)庫或者第三方Restful接口可能需要很長時(shí)間。
我們可能遇到一個(gè)請(qǐng)求會(huì)調(diào)用多個(gè)服務(wù)。比如一次請(qǐng)求調(diào)用Service A、B、C,你肯定不想這樣調(diào)用：
Call service A -> Waiting response from Service A -> call service B -> Watiting ... -> Compose response from A B C
每個(gè)服務(wù)調(diào)用花費(fèi)三秒，整個(gè)請(qǐng)求處理過程將會(huì)花費(fèi)9秒。如果通過下面的做法肯定會(huì)更好。
Call service A Call serviec B -> Waiting response from Service A B C -> compose reponse from A B C Call serviec C
這樣，顯然我們只需要3秒響應(yīng)。 異步和響應(yīng)式微服務(wù)十分有趣，可以參考其他文章。這里我們只關(guān)注Spring boot。
在Spring Boot中使用注解@EnabelAsync注解開啟異步支持。使用@Async將返回CompletableFuture<> 。這些異步方法將會(huì)在后臺(tái)線程中執(zhí)行。如果合理使用異步執(zhí)行，可以避免等待時(shí)間。
以上我們討論了我們無法控制的外部資源，對(duì)于系統(tǒng)內(nèi)部資源我們應(yīng)該避免共享他們。Spring Service and Controller都是單例模式，我們需要十分小心，當(dāng)狀態(tài)改變時(shí)，你需要立刻處理。共享狀態(tài)的其他潛在來源是高速緩存和自定義服務(wù)器范圍的組件（通常是監(jiān)視，安全性等）。如果你必須使用共享狀態(tài)資源，下面是我的建議：
處理不可變對(duì)象。如果對(duì)象是不可變的，則可以避免許多與并發(fā)相關(guān)的問題。如果你需要改變一些東西 - 只需創(chuàng)建一個(gè)新對(duì)象。
并非所有集合都是線程安全的。一個(gè)常見的陷阱是使用HashMap，假設(shè)它是線程安全的（它不是。如果你需要并發(fā)訪問，請(qǐng)使用ConcurrentHashMap，HashTable或其他線程安全的解決方案。）。
不要假設(shè)第三方庫是線程安全的。大多數(shù)代碼都沒有，并且必須控制對(duì)共享狀態(tài)的訪問。
如果你要依賴它 - 學(xué)習(xí)正確的并發(fā)性。我真的建議在實(shí)踐中獲得Java Concurrency的副本。寫于2006年，但在2018年仍然非常相關(guān)。
Spring中的并發(fā)和多線程是重要的主題。在本文中，我想強(qiáng)調(diào)在編寫Spring Boot應(yīng)用程序時(shí)需要注意的關(guān)鍵領(lǐng)域。如果您想在構(gòu)建高要求，高質(zhì)量的服務(wù)時(shí)取得成功，您需要圍繞這一主題做出有意識(shí)的決策和權(quán)衡。我希望通過這篇文章你知道如何開始
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.hztianpu.com/yun/127924.html
摘要：來源是最流行的用于開發(fā)微服務(wù)的框架。以下依次列出了最佳實(shí)踐，排名不分先后。這非常有助于避免可怕的地獄。推薦使用構(gòu)造函數(shù)注入這一條實(shí)踐來自的項(xiàng)目負(fù)責(zé)人。保持業(yè)務(wù)邏輯免受代碼侵入的一種方法是使用構(gòu)造函數(shù)注入。 showImg(https://mmbiz.qpic.cn/mmbiz_jpg/R3InYSAIZkHQ40ly9Oztiart2lESCyjCH0JwFRp3oErlYobhibM...
摘要：作為面試官，我是如何甄別應(yīng)聘者的包裝程度語言和等其他語言的對(duì)比分析和主從復(fù)制的原理詳解和持久化的原理是什么面試中經(jīng)常被問到的持久化與恢復(fù)實(shí)現(xiàn)故障恢復(fù)自動(dòng)化詳解哨兵技術(shù)查漏補(bǔ)缺最易錯(cuò)過的技術(shù)要點(diǎn)大掃盲意外宕機(jī)不難解決，但你真的懂?dāng)?shù)據(jù)恢復(fù)嗎每秒 作為面試官，我是如何甄別應(yīng)聘者的包裝程度Go語言和Java、python等其他語言的對(duì)比分析 Redis和MySQL Redis：主從復(fù)制的原理詳...
摘要：作為面試官，我是如何甄別應(yīng)聘者的包裝程度語言和等其他語言的對(duì)比分析和主從復(fù)制的原理詳解和持久化的原理是什么面試中經(jīng)常被問到的持久化與恢復(fù)實(shí)現(xiàn)故障恢復(fù)自動(dòng)化詳解哨兵技術(shù)查漏補(bǔ)缺最易錯(cuò)過的技術(shù)要點(diǎn)大掃盲意外宕機(jī)不難解決，但你真的懂?dāng)?shù)據(jù)恢復(fù)嗎每秒 作為面試官，我是如何甄別應(yīng)聘者的包裝程度Go語言和Java、python等其他語言的對(duì)比分析 Redis和MySQL Redis：主從復(fù)制的原理詳...
摘要：原文鏈接編程方法論響應(yīng)式與代碼設(shè)計(jì)實(shí)戰(zhàn)序，來自于微信公眾號(hào)次靈均閣正文內(nèi)容在一月的架構(gòu)和設(shè)計(jì)趨勢報(bào)告中，響應(yīng)式編程和函數(shù)式仍舊編列在第一季度的早期采納者中。 原文鏈接：《Java編程方法論：響應(yīng)式RxJava與代碼設(shè)計(jì)實(shí)戰(zhàn)》序，來自于微信公眾號(hào)：次靈均閣 正文內(nèi)容 在《2019 一月的InfoQ 架構(gòu)和設(shè)計(jì)趨勢報(bào)告》1中，響應(yīng)式編程（Reactive Programming）和函數(shù)式...
閱讀 1582·2025-02-07 13:29
閱讀 1007·2024-11-07 18:25
閱讀 131501·2024-02-01 10:43
閱讀 1360·2024-01-31 14:58
閱讀 1147·2024-01-31 14:54
閱讀 83574·2024-01-29 17:11
閱讀 3875·2024-01-25 14:55
閱讀 2392·2023-06-02 13:36
