java低延遲

總覽

以前，我寫(xiě)過(guò)一篇有關(guān)Java之類(lèi)的C的文章。 這是我以前遇到的術(shù)語(yǔ)。 但是，經(jīng)過(guò)思考，我認(rèn)為像Java這樣的C ++是一個(gè)更好的術(shù)語(yǔ)，因?yàn)槟栽谑褂肙OP慣例（不是C慣例），但是您需要投入更多的精力來(lái)管理和回收內(nèi)存。

我現(xiàn)在支持的術(shù)語(yǔ)是“低級(jí)” Java編程。

低延遲和“自然” Java

許多低延遲系統(tǒng)仍使用我稱(chēng)為自然Java的程序進(jìn)行編程。 在大多數(shù)情況下，這是最簡(jiǎn)單，最有效的方法。 當(dāng)您具有大堆大小和低延遲要求時(shí)，這些問(wèn)題才真正開(kāi)始，因?yàn)樗鼈儾荒芎芎玫貐f(xié)同工作。

如果您有一個(gè)已建立的程序，并且重寫(xiě)是不合理的，則需要Zing之類(lèi)的東西，它具有真正的并發(fā)收集器。 盡管您可能會(huì)看到1-4 ms的最嚴(yán)重的停頓，但這與非實(shí)時(shí)系統(tǒng)一樣好。 有傳言說(shuō)RedHat正在產(chǎn)生并發(fā)收集器，但是正如Oracle在G1中發(fā)現(xiàn)的那樣，編寫(xiě)有效的低延遲是非常困難的。 G1工作正常，只是不適合低延遲交易（例如，暫停時(shí)間為1毫秒），我不確定是否會(huì)如此。

如果可以重寫(xiě)關(guān)鍵組件，尤其是出于性能以外的原因而正在考慮這樣做，則可以顯著提高性能，但可以使用更像C ++或C的低級(jí)編程。語(yǔ)言是指您正在使用與那些語(yǔ)言相同的技巧，并且已經(jīng)使用了很長(zhǎng)時(shí)間，但是使用Java。

為什么用Java進(jìn)行低級(jí)編程？

主要原因是集成和易于支持。 低級(jí)Java與自然Java代碼非常緊密地集成在一起。 所有的Java工具都可以很好地使用它，并且它仍然是跨平臺(tái)的（至少是跨OS的）。某些底層技術(shù)是JVM特定的，例如它們可以在OpenJDK / HotSpot上工作，但不能在IBM的JVM上工作，反之亦然。 他們可能會(huì)起作用，但很多都無(wú)濟(jì)于事。 例如，在HotSpot上使用不安全可能會(huì)更快，但在Android上會(huì)明顯慢。

低級(jí)Java編程的另一個(gè)好處是，經(jīng)驗(yàn)豐富的Java開(kāi)發(fā)人員發(fā)現(xiàn)使用它相對(duì)容易。 他們可能會(huì)發(fā)現(xiàn)很難從頭開(kāi)始編寫(xiě)，但是如果使用隱藏更多細(xì)節(jié)的庫(kù)，則可以有效地使用它。

低級(jí)Java有哪些注意事項(xiàng)？

延遲目標(biāo)

除非您在99.9％的時(shí)間內(nèi)運(yùn)行時(shí)間少于1毫秒，否則您現(xiàn)在可以認(rèn)為1毫秒的延遲不是那么快。 Java中最快的系統(tǒng)通常約為100微秒，甚至低于包裝箱外部的20微秒。

如何處理高吞吐量

對(duì)于交易系統(tǒng)，建議您將等待時(shí)間設(shè)置得盡可能低，并且吞吐量通常足夠。 例如，編年史可以以一個(gè)線程的持續(xù)速率以最大爆發(fā)次數(shù)持續(xù)完整的Opera提要。 這是可能的，因?yàn)榫幠晔返臐摲诤芏獭?一條很小的4字節(jié)消息的平均延遲為7納秒。 即使JVM在下一行崩潰時(shí)，它也將保留。 在這一點(diǎn)上吞吐量不是一個(gè)問(wèn)題。

對(duì)于反向測(cè)試，低延遲是不夠的。 這是因?yàn)槟胍龅氖窃诓坏揭幻腌姷臅r(shí)間內(nèi)（理想情況下）重播數(shù)月的數(shù)據(jù)。 在這種情況下，您需要高度的并行性以及能夠在短時(shí)間內(nèi)重播大量數(shù)據(jù)的能力。 為此，我使用了內(nèi)存映射文件，這些文件對(duì)我需要的數(shù)據(jù)進(jìn)行了預(yù)裝查詢(xún)。 如果這些文件為二進(jìn)制格式并適合主內(nèi)存，則可以非常快速地跨線程重復(fù)訪問(wèn)它們。

處理GC。

垃圾收集暫停會(huì)使您減速，因此最快的方法是構(gòu)建引擎是不使用休息時(shí)間。 相反，您給自己一個(gè)預(yù)算，這是您可以合理?yè)碛械淖畲笠恋閳@大小。 這可能是24 GB的Eden。 如果您花了一整天的時(shí)間來(lái)填滿，一天之內(nèi)就不會(huì)收集，即使是次要的收集也是如此。 假設(shè)您可以在晚上或周末停下來(lái)幾秒鐘，則可以在預(yù)定時(shí)間執(zhí)行完全GC，而GC不再是問(wèn)題。

即使這樣，我還是建議盡量減少垃圾并定位內(nèi)存訪問(wèn)模式，以最大程度地提高L1 / L2效率，從而可以將性能提高2-5倍。 L3緩存至少比L1慢10倍，并且如果您不給L1填充垃圾（正如許多Java程序一樣），您的程序?qū)⒏?#xff0c;更一致地運(yùn)行。

將共享內(nèi)存用于IPC

這有兩個(gè)優(yōu)點(diǎn)。

您可以保留所有事件的記錄，以及整天的時(shí)間安排和微不足道的開(kāi)銷(xiāo)。 因?yàn)榭梢员Ａ舾鄶?shù)據(jù)，所以可以在外部，下游或重現(xiàn)錯(cuò)誤來(lái)重現(xiàn)系統(tǒng)的確切狀態(tài)。 這為您提供了基于數(shù)據(jù)驅(qū)動(dòng)的海量測(cè)試，您可以通過(guò)測(cè)試系統(tǒng)實(shí)時(shí)提供生產(chǎn)數(shù)據(jù)，以查看ti在運(yùn)行之前的行為。

實(shí)際上，它可能比其他方法快得多。 一條微小的消息的平均寫(xiě)入延遲為7納秒，并且在不到100納秒的時(shí)間內(nèi)對(duì)另一個(gè)進(jìn)程可見(jiàn)。

固定芯

許多人已經(jīng)嘗試過(guò)固定核心，但并沒(méi)有太大的區(qū)別。 這可能是由于a）應(yīng)用程序的抖動(dòng)過(guò)大，幾乎沒(méi)有關(guān)系，或者b）然后沒(méi)有固定到隔離的內(nèi)核。 我發(fā)現(xiàn)如果綁定到隔離的內(nèi)核，最壞情況的延遲會(huì)從2毫秒下降到10微秒，但固定到非隔離的內(nèi)核似乎根本沒(méi)有幫助。

忙碌中

您不希望關(guān)鍵線程進(jìn)行上下文切換，而避免這種情況的一種方法是永遠(yuǎn)不要放棄內(nèi)核或CPU。 這可以通過(guò)在固定的隔離內(nèi)核上忙于等待來(lái)完成。 我所做的一件事是使用隔離的核心
a）對(duì)最關(guān)鍵的線程有選擇地禁用超線程，而其余的則保留。
b）通過(guò)不對(duì)“垃圾”內(nèi)核進(jìn)行超頻來(lái)更多地使隔離內(nèi)核超頻。 通過(guò)限制不需要最大速度的磁芯產(chǎn)生的熱量，可以達(dá)到這一目的。 例如，假設(shè)您有一個(gè)十六進(jìn)制內(nèi)核，則不讓內(nèi)核0,2,4保持超頻，而超頻內(nèi)核1,3,5則不使用HT，比整個(gè)插槽多使用10％。 我認(rèn)為超頻內(nèi)核在芯片上并不相鄰，因此它們不太可能過(guò)熱。

更大的地址空間集合

Chronicle和OpenHFT的直接存儲(chǔ)的主要功能是它們?cè)试S訪問(wèn)64位大小。 （由于OS / CPU的限制，技術(shù)上只能使用48位）這意味著您可以將TB大小的數(shù)據(jù)集作為一個(gè)集合進(jìn)行管理，而該集合具有在Java內(nèi)存中本地的數(shù)十億條記錄/摘錄。 這樣甚至可以避免JNI障礙或系統(tǒng)調(diào)用來(lái)降低應(yīng)用程序速度。

結(jié)論

如果您的應(yīng)用程序?qū)⑵?0％的時(shí)間用在其代碼的10％或80/20中，則可以使用“自然” Java編寫(xiě)90％的代碼，或者使用第三方庫(kù)。 但是，如果您用低級(jí)Java編寫(xiě)10％的代碼，則可以顯著提高性能。

參考： Vanilla Java博客上的JCG合作伙伴 Peter Lawrey提供了Java 等C ++的低延遲特性。

翻譯自: https://www.javacodegeeks.com/2013/07/c-like-java-for-low-latency.html

java低延遲

總結(jié)

以上是生活随笔為你收集整理的java低延迟_像Java这样的C ++具有低延迟的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。