總覽

以前，我寫過一篇有關Java之類的C的文章。 這是我以前遇到的術語。 但是，經過思考，我認為像Java這樣的C ++是一個更好的術語，因為您仍在使用OOP做法（不是C風格的），但是您需要自己進行更多的工作來管理和回收內存。

我現在支持的術語是“低級” Java編程。

低延遲和“自然” Java

許多低延遲系統仍使用我稱為自然Java的程序進行編程。 在大多數情況下，這是最簡單，最有效的方法。 當您具有大堆大小和低延遲要求時，這些問題才真正開始，因為它們不能很好地協同工作。

如果您有一個已建立的程序，并且重寫是不合理的，則需要Zing之類的東西，它具有真正的并發收集器。 盡管您可能會看到1-4 ms的最嚴重的停頓，這與非實時系統一樣好。 有傳言說RedHat會生成并發收集器，但是正如Oracle在G1中發現的那樣，編寫有效的低延遲非常困難。 G1工作正常，只是不適合低延遲交易（例如，暫停時間為1毫秒），我不確定是否會如此。

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

為什么用Java進行低級編程？

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

低級Java編程的另一個好處是，經驗豐富的Java開發人員發現使用它相對容易。 他們可能會發現很難從頭開始編寫，但是如果使用隱藏更多細節的庫，則可以有效地使用它。

低級Java有哪些注意事項？

延遲目標

除非您在99.9％的時間內運行時間少于1毫秒，否則您現在可以認為1毫秒的延遲不是那么快。 Java中最快的系統通常約為100微秒，甚至低于包裝箱外部的20微秒。

如何處理高吞吐量

對于交易系統，我建議您將等待時間盡可能短，并且吞吐量通常足夠。 例如，編年史可以以一個線程的持續速率以最大爆發次數持續完整的Opera提要。 這是可能的，因為編年史的潛伏期很短。 一條很小的4字節消息的平均延遲為7納秒。 即使JVM在下一行崩潰時，它也將保留。 在這一點上吞吐量不是一個問題。

對于反向測試，低延遲是不夠的。 這是因為您想要做的是在不到一秒鐘的時間內（理想情況下）重播數月的數據。 在這種情況下，您需要高度的并行性以及能夠在短時間內重播大量數據的能力。 為此，我使用了內存映射文件，這些文件具有對所需數據的預裝查詢。 如果這些文件為二進制格式并適合主內存，則可以非常快速地跨線程重復訪問它們。

處理GC。

垃圾收集暫停會使您減速，因此最快的方法是構建引擎是不使用休息時間。 相反，您給自己一個預算，這是您可以合理擁有的最大伊甸園大小。 這可能是24 GB的Eden。 如果您花了一整天的時間來填滿，一天之內就不會收集，即使是次要的收集也是如此。 假設您可以在晚上或周末停下來幾秒鐘，則可以在預定時間執行完全GC，而GC不再是問題。

即使這樣，我還是建議盡量減少垃圾并本地化內存訪問模式以最大化L1 / L2效率，這可以導致性能提高2-5倍。 L3緩存至少比L1慢10倍，并且如果您不給L1填充垃圾（正如許多Java程序一樣），您的程序將更快，更一致地運行。

將共享內存用于IPC

這有兩個優點。

您可以保留所有事件的記錄，以及整天的時間安排和微不足道的開銷。 因為您可以保留更多數據，所以可以在外部，下游或重現錯誤來重現系統的確切狀態。 這為您提供了基于數據驅動的海量測試，您可以通過測試系統實時提供生產數據，以查看ti在實時運行之前的行為。

實際上，它可能比其他方法快得多。 一條微小的消息平均可以寫入7納秒的延遲，并且在不到100納秒的時間內對另一個進程可見。

固定芯

許多人已經嘗試過固定核心，但并沒有太大的區別。 這可能是由于a）應用程序的抖動過大，幾乎沒有關系，或者b）然后沒有固定到隔離的內核。 我發現如果綁定到隔離的內核，最壞情況的延遲會從2毫秒下降到10微秒，但固定到非隔離的內核似乎根本沒有幫助。

忙碌中

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

更大的地址空間集合

Chronicle和OpenHFT的直接存儲的主要功能是它們允許訪問64位大小。 （由于OS / CPU的限制，技術上只能使用48位）這意味著您可以將TB大小的數據集作為一個集合進行管理，而該集合具有Java內存中本來就有數十億條記錄/節選。 這樣甚至可以避免JNI障礙或系統調用來降低應用程序速度。

結論

如果您的應用程序將其90％的時間用在其代碼的10％或80/20中，則可以使用“自然” Java編寫90％的代碼，或者使用第三方庫。 但是，如果您用低級Java編寫10％的代碼，則可以顯著提高性能。

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

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

總結

以上是生活随笔為你收集整理的像Java这样的C ++具有低延迟的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。