再次出現(xiàn)。. 回顧 Peters關(guān)于Unsafe用法的書面概述 ，我將簡要介紹一下Java中的低級技術(shù)如何通過啟用更高級別的抽象或允許Java性能級別來節(jié)省開發(fā)工作可能很多人都不知道。

我的主要觀點(diǎn)是表明，將對象轉(zhuǎn)換為字節(jié)，反之亦然是一個重要的基礎(chǔ)，實際上影響了任何現(xiàn)代Java應(yīng)用程序。

硬件喜歡處理字節(jié)流，而不是處理通過指針連接的對象圖，因為“所有內(nèi)存都是磁帶” （如果我沒記錯的話，M.Thompson ..）。

因此，許多基本技術(shù)很難與原始Java堆對象一起使用：

• 內(nèi)存映射文件 –一種出色而簡單的技術(shù)，可安全，快速，輕松地保存應(yīng)用程序數(shù)據(jù)。
• 網(wǎng)絡(luò)通信基于發(fā)送字節(jié)數(shù)據(jù)包
• 進(jìn)程間通信 （共享內(nèi)存）
• 當(dāng)今服務(wù)器的大主內(nèi)存 （64GB至256GB）。 （GC問題）
• CPU高速緩存最適合在內(nèi)存中以連續(xù)字節(jié)流形式存儲的數(shù)據(jù)

因此在大多數(shù)情況下使用Unsafe類有助于將Java對象圖轉(zhuǎn)換為連續(xù)內(nèi)存區(qū)域，反之亦然

• [性能增強(qiáng)] 對象序列化或
• 包裝器類，以簡化對存儲在連續(xù)內(nèi)存區(qū)域中的數(shù)據(jù)的訪問。

（本文的代碼和示例可在此處找到）

基于序列化的堆外

考慮一個零售Web應(yīng)用程序，其中可能有數(shù)百萬個注冊用戶。 實際上，我們不希望在關(guān)系數(shù)據(jù)庫中表示數(shù)據(jù)，因為所有必要的操作是在用戶登錄后快速檢索與用戶相關(guān)的數(shù)據(jù)。此外，我們希望快速遍歷社交圖。

讓我們看一個簡單的用戶類，其中包含一些屬性和構(gòu)成社交圖的“朋友”列表。

將其存儲在堆上的最簡單方法是簡單的大型HashMap。

或者，可以使用堆外映射來存儲大量數(shù)據(jù)。 堆外映射將其鍵和值存儲在本機(jī)堆中，因此垃圾回收不需要跟蹤此內(nèi)存。 此外，可以告知本機(jī)堆自動與磁盤（內(nèi)存映射文件）同步。 甚至在您的應(yīng)用程序崩潰時也可以使用，因為操作系統(tǒng)可以管理對更改的內(nèi)存區(qū)域的回寫。

有一些具有各種功能集的開源堆外地圖實現(xiàn)（例如ChronicleMap ），在此示例中，我將使用一種簡單且簡單的實現(xiàn)，該實現(xiàn)具有快速迭代（可選的全掃描搜索）和易用性的特點(diǎn)。

序列化用于存儲對象，反序列化用于將它們再次拉到Java堆。 令人愉快的是，我寫了這個星球上最快的，完全符合JDK的對象序列化 （afaik），因此我將利用它。

完成：

• 通過內(nèi)存映射文件實現(xiàn)持久性（映射將在創(chuàng)建時重新加載）。
• Java Heap仍然是空的，無法使用Full GC <100ms進(jìn)行真實的應(yīng)用程序處理。
• 整體內(nèi)存消耗明顯減少。 序列化的用戶記錄約為60個字節(jié)，因此理論上3億條記錄可容納180GB的服務(wù)器內(nèi)存。 無需引發(fā)大數(shù)據(jù)標(biāo)志并在AWS上運(yùn)行4096個hadoop節(jié)點(diǎn)。

比較常規(guī)內(nèi)存中的Java HashMap和基于快速序列化的持久性堆外映射（擁有1500萬條用戶記錄），將顯示以下結(jié)果（在3Ghz較舊的XEON 2×6上）：

	消耗的Java堆（MB）	完整GC	本機(jī)堆（MB）	每秒鐘獲取/輸入操作	所需的VM大小（MB）
哈希圖	6.865,00	26,039	0	3.800.000,00	12.000,00
OffheapMap（基于序列化）	63,00	0,026	3.050	750.000,00	500,00

[ 測試源/博客項目 ]注意：您至少需要16GB的RAM才能執(zhí)行它們。

如人們所見，無論如何，即使進(jìn)行快速序列化，訪問性能也要付出沉重的代價（約5倍）：與其他持久性替代方案相比，其性能仍然更好（每個“ get”操作“ put（）”為1-3微秒）非常相似）。

使用JDK序列化的速度至少要慢5到10倍（下面直接比較），因此使該方法無用。

相對于更高的抽象水平，交易性能有所提高：“使我服務(wù)器化”

單個服務(wù)器將無法為成千上萬的用戶提供服務(wù)，因此我們需要以某種方式在進(jìn)程之間甚至跨機(jī)器共享數(shù)據(jù)，甚至更好。

使用快速實現(xiàn)，可以為網(wǎng)絡(luò)消息傳遞慷慨地使用（快速）序列化。 再說一次：如果運(yùn)行速度要慢5至10倍，那將是不可行的。 替代方法需要更多數(shù)量級的工作才能獲得相似的結(jié)果。

通過使用Actor實現(xiàn)（異步ftw！）包裝持久性堆外哈希映射，一些代碼行構(gòu)成了具有基于TCP和HTTP接口的持久性KeyValue服務(wù)器（使用kontraktor actors ）。 當(dāng)然，如果稍后決定，仍可以在過程中使用Actor。

現(xiàn)在，這是一個微服務(wù)。 鑒于它沒有進(jìn)行任何優(yōu)化的嘗試并且是單線程的 ，因此它的速度相當(dāng)快[與上述XEON機(jī)器相同]：

• 每秒280_000次成功的遠(yuǎn)程查找
• 如果失敗查找，則為800_000（找不到密鑰）
• 基于序列化的TCP接口（1個內(nèi)襯）
• REST-of-us（1個班輪）的嚴(yán)格Web服務(wù)。

[ 來源：KVServer，KVClient ]注意：您至少需要16GB的RAM才能執(zhí)行測試。

現(xiàn)實世界中的實現(xiàn)可能希望通過將接收到的序列化對象byte []直接放入映射中而不是對其進(jìn)行兩次編碼（一次編碼/解碼以便通過網(wǎng)絡(luò)傳輸，然后解碼/編碼以用于拆分映射）來使性能提高一倍。

“ RestActorServer.Publish（..）;” 除了原始tcp之外，還可以將KVActor作為Web服務(wù)公開：

使用flyweight包裝器/結(jié)構(gòu)獲得類似C的性能

通過序列化，常規(guī)Java對象將轉(zhuǎn)換為字節(jié)序列。 一個可以做相反的事情：創(chuàng)建包裝器類，該包裝器類從基礎(chǔ)字節(jié)數(shù)組或本機(jī)內(nèi)存地址的固定或計算位置讀取數(shù)據(jù)。 （例如，請參閱此博客文章 ）。

通過移動基本指針，僅通過移動包裝器的偏移量就可以訪問不同的記錄。 復(fù)制這樣的“打包對象”歸結(jié)為內(nèi)存副本。 此外，以這種方式編寫分配免費(fèi)的代碼非常容易。 缺點(diǎn)是，與常規(guī)Java對象相比，讀/寫單個字段會降低性能。 這可以通過使用Unsafe類來彌補(bǔ)。

如引用的博客文章中所示，“ flyweight”包裝器類可以手動實現(xiàn)，但是隨著代碼的增長，這種情況變得難以維護(hù)。

快速序列化提供了一個副產(chǎn)品“結(jié)構(gòu)仿真”，支持在運(yùn)行時從常規(guī)Java類創(chuàng)建flyweight包裝器類。 這樣可以在很大程度上避免應(yīng)用程序代碼中的低級字節(jié)擺弄。

常規(guī)Java類如何映射到平面內(nèi)存（fst-struct）：

當(dāng)然，有一些更簡單的工具可以幫助減少編碼的手動編程（例如Slab ），這可能更適合許多情況并且使用較少的“魔術(shù)”。

使用不同的方法（悲傷事實傳入）可以期待什么樣的性能？

讓我們采用以下結(jié)構(gòu)類，包括價格更新和表示可交易工具（例如股票）的嵌入式結(jié)構(gòu)，并使用各種方法對其進(jìn)行編碼：

代碼中的“結(jié)構(gòu)”

純編碼性能：

結(jié)構(gòu)	fast-Ser（無共享裁判）	快速服務(wù)	JDK Ser（未共享）	JDK系列
26.315.000,00	7.757.000,00	5.102.000,00	649.000,00	644.000,00

具有消息傳遞吞吐量的真實世界測試：

為了對實際應(yīng)用中的差異進(jìn)行基本估算，我做了一個實驗，當(dāng)通過可靠的UDP消息以高速率發(fā)送和接收消息時，不同的編碼如何執(zhí)行：

考試：

發(fā)送方盡可能快地對消息進(jìn)行編碼，然后使用可靠的多播將其發(fā)布，訂戶接收并對其進(jìn)行解碼。

結(jié)構(gòu)	fast-Ser（無共享裁判）	快速服務(wù)	JDK Ser（未共享）	JDK系列
6.644.107,00	4.385.118,00	3.615.584,00	81.582,00	79.073,00

（在I7 / Win8，XEON / Linux上進(jìn)行的測試得分略高，結(jié)構(gòu)的msg大小約為70字節(jié)，序列化約為60字節(jié)）。

與最低速度相比，最慢速度：82。測試突出顯示了微基準(zhǔn)測試未涵蓋的問題：編碼和解碼應(yīng)執(zhí)行類似的操作，因為實際吞吐量由Min（編碼性能，解碼性能）確定。 出于未知原因，JDK序列化設(shè)法對每秒測試的消息進(jìn)行編碼，例如每秒500_000次，解碼性能僅為每秒80_000次，因此在測試中，接收器Swift下降：

”

…

*****接收速率統(tǒng)計：每秒80351 **********

*****接收速率統(tǒng)計：每秒78769 **********

SUB-ud4q已被服務(wù)1的PUB-9afs丟棄

致命的，無法跟上。 退出

“

（在此處創(chuàng)建背壓可能不是解決此問題的正確方法！）

結(jié)論

• 快速序列化允許在分布式應(yīng)用程序中實現(xiàn)某種程度的抽象，如果序列化實現(xiàn)是
  - 太慢了
  –不完整。 例如無法處理任何可序列化的對象圖 –需要手動編碼/修改。 （會對演員消息類型，期貨，孢子，維護(hù)噩夢施加許多限制）
• 諸如“不安全”之類的低級實用程序可實現(xiàn)數(shù)據(jù)的不同表示，從而為特殊工作負(fù)載提供超常的吞吐量或有保證的等待時間邊界（無分配主路徑）。 使用JDK的公共工具集不可能實現(xiàn)這些目標(biāo)。
• 在分布式系統(tǒng)中，通信性能至關(guān)重要。 查看上面的數(shù)字，刪除不安全并不是最大的麻煩。.JSON或XML不能解決此問題。
• 盡管HotSpot VM已達(dá)到非凡的性能和可靠性水平，但JDK的某些部分卻浪費(fèi)了CPU，就像沒有明天一樣。 考慮到我們生活在分布式應(yīng)用程序和數(shù)據(jù)時代，應(yīng)該很容易實現(xiàn)（而不是手動編碼）通過網(wǎng)絡(luò)移動內(nèi)容。

附錄：有限的延遲

快速的Ping Pong RTT延遲基準(zhǔn)測試表明Java可以輕松地與C解決方案競爭，只要主要路徑是無分配的，并且采用了上述技術(shù)即可：

[學(xué)分：圖表和使用HdrHistogram進(jìn)行的測量]

這是一個“實驗”，而不是一個基準(zhǔn)測試（因此，請不要閱讀：“ 證明：Java比C更快” ），它表明低級Java至少可以在此低級領(lǐng)域與C競爭。

當(dāng)然，它不是完全慣用的 Java代碼，但是與JNI或純C（++）解決方案相比，它仍然更易于處理，移植和維護(hù)。 低延遲的C（++）代碼也不是慣用的！

翻譯自: https://www.javacodegeeks.com/2015/01/a-persistent-keyvalue-server-in-40-lines-and-a-sad-fact.html

總結(jié)

以上是生活随笔為你收集整理的40行中的持久性KeyValue Server和一个可悲的事实的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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