資訊專(zhuān)欄INFORMATION COLUMN
摘要：首先先解讀下這個(gè)報(bào)警內(nèi)容，原因活躍線(xiàn)程數(shù)過(guò)多，是監(jiān)聽(tīng)的端口號(hào)用來(lái)獲取虛擬機(jī)各項(xiàng)信息，代表著此時(shí)的線(xiàn)程數(shù)，是設(shè)置的報(bào)警閾值。
前言
前天，一位21世紀(jì)的好好青年正在工位上默念社會(huì)主義大法好的時(shí)候，釘釘上又報(bào)警了（公司項(xiàng)目接入了open-faclon監(jiān)控，指標(biāo)不正常會(huì)報(bào)警給釘釘?shù)臋C(jī)器人），無(wú)奈默默流淚揮手告別社會(huì)主義大法開(kāi)始定位線(xiàn)上問(wèn)題。
報(bào)警內(nèi)容首先我們先來(lái)看下報(bào)警信息，為防止泄露公司信息，對(duì)項(xiàng)目名稱(chēng)和監(jiān)聽(tīng)的端口號(hào)進(jìn)行了抹除：
這個(gè)問(wèn)題曾多次出現(xiàn)，一直沒(méi)有抓到導(dǎo)致這個(gè)問(wèn)題的鬼。首先先解讀下這個(gè)報(bào)警內(nèi)容，原因：活躍線(xiàn)程數(shù)過(guò)多，jmxport是監(jiān)聽(tīng)的jmx端口號(hào)用來(lái)獲取虛擬機(jī)各項(xiàng)信息，5118>=1500:5118代表著此時(shí)的線(xiàn)程數(shù)，1500是設(shè)置的報(bào)警閾值。
為什么要將閾值設(shè)置為1500呢（如果你對(duì)這個(gè)閾值的設(shè)置并不感興趣，可直接跳過(guò)閱讀）？
為了搞清楚這個(gè)閾值的建立規(guī)則，我可是下了大功夫的....操作系統(tǒng)可以簡(jiǎn)單的分為32位和64位，每一個(gè)32位進(jìn)程都獨(dú)享4G的虛擬地址空間，其中低2G是給用戶(hù)的，高2G是給系統(tǒng)預(yù)留的。也就是每一個(gè)32位進(jìn)程中，實(shí)際能夠使用的內(nèi)存不到2G。64位下由于尋址操作變?yōu)?的64次方基本可以看做沒(méi)有限制。介紹完這個(gè)，就來(lái)介紹下博主監(jiān)控程序的運(yùn)行環(huán)境，4核8GB內(nèi)存64為linux系統(tǒng)java8，程序的jvm參數(shù)為-server -Xms4g -Xmx4g -Xmn2g。-Xss 為jvm啟動(dòng)的每個(gè)線(xiàn)程分配的內(nèi)存大小，如果未設(shè)置，則默認(rèn)是1m(java8)。系統(tǒng)總內(nèi)存為8G，堆內(nèi)存設(shè)置為了4G，可用給分配線(xiàn)程的內(nèi)存不會(huì)超過(guò)4G，理論上可以達(dá)到最大的線(xiàn)程數(shù)應(yīng)該是4*1024個(gè)（實(shí)際會(huì)更少，系統(tǒng)文件、元空間等都會(huì)占用大量?jī)?nèi)存）。搜索了大量相關(guān)資料，只是簡(jiǎn)單的計(jì)算出了一個(gè)理想情況下線(xiàn)程數(shù)的最大值，對(duì)于閾值設(shè)置并沒(méi)有找到一個(gè)很權(quán)威的說(shuō)法。所以博主就大膽猜測(cè)，這個(gè)閾值應(yīng)該是運(yùn)維根據(jù)自己的經(jīng)驗(yàn)設(shè)置的，之所以設(shè)置這個(gè)閾值是為了更好的得知服務(wù)器的運(yùn)行狀況，當(dāng)超過(guò)這個(gè)數(shù)了，我們應(yīng)當(dāng)檢測(cè)其原因，如果是程序代碼造成的問(wèn)題就需要對(duì)癥下藥，如果是環(huán)境問(wèn)題或者流量確實(shí)達(dá)到這個(gè)閾值，我們就需要去考慮做集群做高可用。
如何定位線(xiàn)程過(guò)多的原因
jdk給了我們很多好用的工具，如果對(duì)jvm一點(diǎn)都沒(méi)有了解過(guò)得同學(xué)建議大家讀一下我之前的寫(xiě)的jvm相關(guān)的學(xué)習(xí)筆記。首先定位java項(xiàng)目進(jìn)程pid,然后打印堆棧文件并分析堆棧文件。其過(guò)程如下圖所示:
接下來(lái)我們著重來(lái)分析erp.txt這個(gè)文件，針對(duì)于線(xiàn)程過(guò)多的排查主要是查詢(xún)程序內(nèi)線(xiàn)程池是否使用得當(dāng)，我們可以根據(jù)是否存在大量相似的線(xiàn)程名來(lái)判斷。經(jīng)過(guò)分析發(fā)現(xiàn)文件中大量存在OkHttp ConnectionPool，如下圖所示:
經(jīng)過(guò)匹配，OkHttp Connection達(dá)到4000多個(gè)，然后再次定位，發(fā)現(xiàn)系統(tǒng)中有調(diào)用php的代碼使用OKhttp，代碼如下所示：
public final class HttpUtil {
public static String doPost(String url, String content) throws IOException {
OkHttpClient client = new OkHttpClient();
RequestBody body = RequestBody.create(MediaType.parse("application/json; charset=utf-8"), content);
Request request = new Request.Builder().url(url).post(body).build();
Response response = client.newCall(request).execute();
return response.body().string();
}
public static String doGet(String url) throws IOException {
OkHttpClient httpClient = new OkHttpClient();
Request request = new Request.Builder().url(url).build();
Response response = httpClient.newCall(request).execute();
return response.body().string();
}
}
簡(jiǎn)單了解下OkHttpClient
線(xiàn)程過(guò)多是OkHttpClient導(dǎo)致的，我們就需要對(duì)癥下藥，簡(jiǎn)單了解下其用法。翻看其源碼可以發(fā)現(xiàn)如下圖注釋:
簡(jiǎn)單翻譯下：對(duì)于所有的http請(qǐng)求，建議你創(chuàng)造一個(gè)OkHttpClient實(shí)例并重復(fù)使用這是因?yàn)槊總€(gè)實(shí)例都有它自己的連接池和線(xiàn)程池，重用連接池和線(xiàn)程池可以減少延遲節(jié)省內(nèi)存，下面的是OKHttpClinet的一些常見(jiàn)用法。至此我們已經(jīng)完全清楚此次問(wèn)題的來(lái)龍去脈，只需要重用OkHttpClient就好....
總結(jié)解決這個(gè)問(wèn)題非常簡(jiǎn)單，只要將OKhttpClient設(shè)置為單例，按照推薦用法去創(chuàng)建即可解決，不過(guò)這篇博客的價(jià)值并不在于此，而是和大家探討一些解決問(wèn)題的思路，如果你有更好的辦法，歡迎留言。問(wèn)題解決了，我繼續(xù)默念社會(huì)主義大法好了^.^
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://hztianpu.com/yun/69161.html
摘要：直接顯示了一個(gè)疑似內(nèi)存泄漏的問(wèn)題。然后分析文件給出的信息，發(fā)現(xiàn)一個(gè)叫的類(lèi)。文件里面說(shuō)的內(nèi)存泄漏的大概的意思就是說(shuō)，這個(gè)類(lèi)里面的存放的東西太多了，爆掉了。修改了代碼將調(diào)用的地方改成了單例。修改完線(xiàn)上跑了一段日子，后來(lái)也沒(méi)有出現(xiàn)過(guò)這樣的問(wèn)題。 問(wèn)題描述: ????早上去公司上班,突然就郵件一直報(bào)警,接口報(bào)異常,然后去查服務(wù)器的運(yùn)行情況,發(fā)現(xiàn)java的cpu爆了.接著就開(kāi)始排查問(wèn)題 問(wèn)題解決...
摘要：記一次頁(yè)面卡頓排查前述前段時(shí)間上線(xiàn)的一個(gè)移動(dòng)端的項(xiàng)目，由于開(kāi)發(fā)時(shí)間倉(cāng)促，一直被用戶(hù)投訴頁(yè)面卡頓。這顯然要導(dǎo)致卡頓?？偨Y(jié)這只是頁(yè)面卡頓的一個(gè)點(diǎn)，當(dāng)然還有很多，我們的頁(yè)面卡頓就是由這樣一個(gè)一個(gè)的點(diǎn)造成的。 記一次頁(yè)面卡頓排查 前述 前段時(shí)間上線(xiàn)的一個(gè)移動(dòng)端的項(xiàng)目，由于開(kāi)發(fā)時(shí)間倉(cāng)促，一直被用戶(hù)投訴頁(yè)面卡頓?，F(xiàn)在終于有時(shí)間來(lái)好好排查一下，看到底是什么原因。業(yè)務(wù)代碼都不是自己寫(xiě)的，這是頗為頭疼的...
摘要：此時(shí)我想到了福爾摩斯說(shuō)過(guò)的一句話(huà)當(dāng)你排除掉各種不可能出現(xiàn)的情況之后，剩下的情況無(wú)論多么難以置信，都是真相。福爾摩斯冷靜下來(lái)想一想，這個(gè)線(xiàn)程，有可能靜悄悄地退出了嗎，沒(méi)留下半點(diǎn)異常日志從理論上來(lái)說(shuō)，不可能。配置建議最后，附上一份配置建議。 1、事發(fā) 我們有個(gè)視頻處理程序，基于 SpringBoot，會(huì)啟動(dòng)幾個(gè)線(xiàn)程來(lái)跑。要退出程序時(shí)，會(huì)發(fā)送一個(gè)信號(hào)給程序，每個(gè)線(xiàn)程收到信號(hào)后會(huì)平滑退出，等全...
摘要：當(dāng)然，如果你的核心數(shù)夠多，到個(gè)線(xiàn)程的并行度不滿(mǎn)足的話(huà)，也可以自定義一個(gè)線(xiàn)程池來(lái)執(zhí)行，不過(guò)這樣的話(huà)，要注意自己維護(hù)這個(gè)線(xiàn)程池的初始化，釋放等等操作了。 事情起源于一個(gè)bug排查，一個(gè)AsyncTask的子類(lèi)，執(zhí)行的時(shí)候發(fā)現(xiàn)onPreExecute方法執(zhí)行了，doInBackground卻遲遲沒(méi)有被調(diào)用。懂AsyncTask一些表面原理的都知道，onPreExecute方法是在主線(xiàn)程執(zhí)行，...
閱讀 1337·2021-11-17 09:33
閱讀 3763·2021-09-28 09:42
閱讀 3554·2021-09-13 10:35
閱讀 2821·2021-09-06 15:00
閱讀 2608·2021-08-27 13:12
閱讀 3739·2021-07-26 23:38
閱讀 2117·2019-08-30 15:55
閱讀 683·2019-08-30 15:53
