遷移桌面程序到MS Store(11)——應用SVG圖標

在傳統桌面程序中,對圖標的使用大多是直接嵌入JPG或者PNG的圖片。在祖傳的1366×768分辨率下,並沒有什麼問題。相對於手機硬件的突飛猛進,也側面反映了PC行業的落寞和桌面程序開發的不思進取。用360衛士的群眾並不能倒推PC行業的升級。反倒是水果公司雙高的利潤和口碑讓人很是眼饞。加之某軟跳出來教豬隊友做硬件。現在倒是有些起色,1080p的屏幕已是標配,4k也算常見。那麼傳統桌面程序在升級過程中,就會遇到今天要討論的,如何解決高分辨率下圖標模糊的問題。

一種解決方案是按最高的分辨率提供圖片。這種適合較大的圖片,比如背景啥的。另一種就是今天要討論的,針對當前流行的、扁平化圖標的解決方案。

 從本篇的標題可以看出,我們希望應用SVG矢量圖來適應各種分辨率的情況。以WPF程序為例,首先要面對的問題是,WPF並不支持像嵌入JPG/PNG圖標這樣,直接使用SVG圖標。大動干戈的引用第三方library通過自定義類型來支持SVG並不是本文的目的。這裏我們要介紹如何通過字體文件,進而在WPF或UWP中使用SVG圖標的方式。

雖然WPF不支持直接使用SVG文件,但是Windows是支持矢量字體的。而我們的目的就是要將圖標以字體的形式在WPF程序中显示。具體使用的字體TrueType,則是由微軟和蘋果共同開發的字體類型標準,該字體文件的擴展名是.ttf。

接下來我們依然是通過Sample工程來說明。首先給出GitHub的地址:

首先我們打開WpfAppWithPNGs工程,圖標的使用代碼如下:

        <Image Grid.Row="0" Grid.Column="0"  Width="32" Height="32" Source="Resources/Airplane_Off.png" ></Image>
        <Image Grid.Row="0" Grid.Column="1"  Width="64" Height="64" Source="Resources/Airplane_On.png" ></Image>
        <Image Grid.Row="0" Grid.Column="2"  Width="96" Height="96" Source="Resources/Bluetooth_Off.png"  ></Image>
        <Image Grid.Row="0" Grid.Column="3"  Width="128" Height="128" Source="Resources/Bluetooth_On.png"  ></Image>

 

這裏主要有兩個問題,因為我們默認提供的是32×32的圖標,因此除了第一列Width和Height設置為32的圖標,其他的圖標都存在模糊的問題。第二個問題是針對圖標的每一種顏色,都需要對應提供不同的圖標文件(圖中的例子需要有灰色和藍色兩份文件)。相對的SVG圖標僅僅需要一份文件。即可在程序中動態設定不同的顏色了。

這裏先給出最終WPF項目中,對SVG圖標的引用的代碼,然後我們再進行詳細解釋。對應的工程名為WpfAppWithFontIcons。

        <TextBlock Grid.Row="0" Grid.Column="0" Text="{x:Static local:FontIcons.airplane_mode_circ}"   Foreground="Gray"  FontSize="32" ></TextBlock>
        <TextBlock Grid.Row="0" Grid.Column="1" Text="{x:Static local:FontIcons.airplane_mode_circ}"  Foreground="{StaticResource dellBlue}"  FontSize="64" ></TextBlock>
        <TextBlock Grid.Row="0" Grid.Column="2" Text="{x:Static local:FontIcons.bluetooth_inactive}"   Foreground="Orange"  FontSize="96" ></TextBlock>
        <TextBlock Grid.Row="0" Grid.Column="3" Text="{x:Static local:FontIcons.bluetooth_inactive}"    Foreground="Brown"  FontSize="128" ></TextBlock>

代碼最大的不同應該是由<Image/>標籤更改為<TextBlock/>標籤,這是因為我們是通過ttf字體文件,曲線救國的方式來使用SVG圖標。

具體的步驟如下:

準備SVG圖標文件,將這些文件打包成一整個ttf字體文件。打包的方式有很多種,通常我使用的是IcoMoon的免費解決方案。地址如下:

通過這個網站選擇SVG圖標文件上傳,打包生成一個zip文件。解壓後文件夾結構如下圖:

ttf文件在fonts文件夾中,實際使用時,需要作為資源文件,添加到WPF工程中。點擊圖中的demo.html會打開一個本地網頁,可用於查找ttf文件中包含的SVG圖標,以及對應的unicode。實際我們是通過對unicode的引用來显示SVG圖標的。

完整的project結構如下圖,Fonts文件夾是手動添加用來放置ttf文件。ttf文件名字都是根據項目需要來取,並不固定。

ttf字體文件需要以<FontFamily/>的形式添加到項目的<Resources/>節點中。然後再通過<Style/>指定給<TextBlock/>。當然不在<Resources/>節點定義Style,而是在每個<TextBlock/>中指定FontFamily屬性也是可以的。有關XAML的語法細節,回字的四種寫法什麼的,這裏略過不提。

    <Window.Resources>
        <FontFamily x:Key="Fonticon">/Fonts/rcc-fonticon-ribbon-v2.ttf#rcc-fonticon-ribbon-v2</FontFamily>
        <Style TargetType="TextBlock">
            <Setter Property="FontFamily" Value="{StaticResource Fonticon}" ></Setter>
        </Style>
        <SolidColorBrush x:Key="dellBlue">#007DB8</SolidColorBrush>
    </Window.Resources>

這裏說明一下“/Fonts/rcc-fonticon-ribbon-v2.ttf#rcc-fonticon-ribbon-v2”值的定義,#前面的是文件路徑,#後面的是font name,查看的方法是雙擊ttf文件,參考下圖。

在定義好FontFamily之後,我們並不推薦直接將unicode寫到XAML或.cs文件中。因為在XAML中,你需要如下編寫:

<TextBlock Grid.Row="0" Grid.Column="0" Text="&#xe900;" Foreground="Gray"  FontSize="32" ></TextBlock>

而在C#代碼中,又需要以下面這種格式:

textBlockAirplane.Text = "\ue900"

兩種不統一的格式會在將來修改時帶來極大的困難,特別是圖標被多處引用時,全局的查找替換根本就是噩夢。此外,毫無意義的unicode值的可讀性根本等於0。正常人類無法將”&#xe900;”,”\ue900″和Airplane的圖標聯繫起來。

我推薦的做法是生成一個FontIcons Class,以string類型屬性的形式暴露出來。這樣可以獲得IDE智能語法提示的支持,更新時也僅需修改這個Class,Find All Reference更是方便無比。同時無論在XAML文件,還是C#代碼中,我們看到的都是統一的“FontIcons.airplane_mode_circ”。

    public static class FontIcons
    {
        public static string airplane_mode_circ { get; } = "\ue900";
        public static string bluetooth_inactive { get; } = "\ue901";
        public static string brightness { get; } = "\ue902";
        public static string brightness_inactive { get; } = "\ue903";
        public static string browse_inactive { get; } = "\ue904";
        public static string camera { get; } = "\ue905";
    }

那麼我們是不是需要手工來編寫FontIcons Class呢?大哥我們是能把午飯(我不愛喝咖啡)轉換成Code的生物啊!當然是寫個小工具來自動生成了。在Sample庫中,參考IcoMoonReader工程,只需將IcoMoon生成的.svg文件(icomoon.zip解壓后的fonts文件夾里)丟在IconMoonReader.exe同級目錄,即可生成相應代碼。

 其實只有一個方法啦,使用時需要注意具體的文件名是否正確。

            using (var stream = new FileStream("rcc-fonticon-ribbon-v2.svg", FileMode.Open))
            {
                using (var reader = new StreamReader(stream))
                {
                    var pattern = "unicode(\\S)*\\sglyph-name(\\S)*\"";
                    var input = reader.ReadToEnd();
                    foreach (Match match in Regex.Matches(input, pattern))
                    {
                        pattern = "\"\\S*\"";
                        var list = new List<string>();
                        foreach (var result in Regex.Matches(match.Value, pattern))
                        {
                            list.Insert(0, result.ToString());
                        }
                        var name = list[0].Replace("\"", "").Replace("-","_");
                        var code = list[1].Replace("&#x", "\\u").Replace(";", "");
                        Console.WriteLine($"public static string {name} {{ get; }} = {code};");
                    }
                }
            }

把生成的C#字符串定義貼到具體工程的FontIcons Class(名字隨意)。

這樣一個優秀的解決方案如果僅支持WPF,那又談何遷移到MS Store呢?實際上這套機制放到UWP工程中也是可以的。雖然UWP可以通過SvgImageSource屬性原生支持SVG了,但我們的這套方案在圖標的應用方面毫不遜色,甚至可以說更為方便。具體的例子可以參考AppWithFontIcon工程。在這個UWP的工程中,除了放ttf文件的位置我換到了現成的Assets文件夾,幾乎沒有改變。

        <TextBlock Grid.Row="0" Grid.Column="0" Text="{x:Bind local:FontIcons.airplane_mode_circ}"   Foreground="Gray"  FontSize="32" ></TextBlock>
        <TextBlock Grid.Row="0" Grid.Column="1" Text="{x:Bind local:FontIcons.airplane_mode_circ}"  Foreground="{StaticResource dellBlue}"  FontSize="64" ></TextBlock>
        <TextBlock Grid.Row="0" Grid.Column="2" Text="{x:Bind local:FontIcons.bluetooth_inactive}"   Foreground="Orange"  FontSize="96" ></TextBlock>
        <TextBlock Grid.Row="0" Grid.Column="3" Text="{x:Bind local:FontIcons.bluetooth_inactive}"    Foreground="Brown"  FontSize="{x:Bind DynamicFontSize(),Mode=OneWay,FallbackValue=128}" ></TextBlock>

因為UWP沒有了x:static關鍵字,所以我換成了x:Bind。換成x:Bind之後甚至可以動態的響應值的變化。比如我在這裏把FontSize做了一個x:bind到DynamicFontSize()方法,讓字體隨着界面改變,動態的變大變小。雖然並沒有什麼卵用……但是Demo的時候可以增加點噱頭……

本篇到此結束,照例貼上Github地址:

感謝耐着性子看到這裏的同學!

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置台北網頁設計,各種案例分享

圈養不人道 海洋世界取消虎鯨表演

摘錄自2019年12月25日東網報導

外形搶眼的虎鯨素來是水族館明星,惟圈養做法引來不合人道的質疑。美國佛羅里達州「奧蘭多海洋世界」(SeaWorld Orlando)近日宣布,明年元旦將取締虎鯨表演節目,改由介紹虎鯨的參觀項目取而代之。

虎鯨節目「一個海洋」自2011年推出,是一個主題圍繞保育的23分鐘表演,亦是海洋世界首個沒有訓練員在水中參與的項目。該節目下周二(31日)除夕將上演最後一場,其後會改為舉行名為「邂逅虎鯨」的參觀項目。

海洋世界的動物學團隊主管多爾德(Chris Dold)則介紹,新節目將向遊客解釋虎鯨在海洋生態中的角色,以及保護其棲息地的重要性等;又指節目具教育價值,與公園致力推廣動物救援及保護的信念相符。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

北海道核電站少報一半污染

摘錄自2019年12月26日共同社報導

日本北海道電力公司周二(24日)發布消息稱,公司自1988年起就一直向周邊地方政府少報「泊核電站」向大氣排放的放射性氣體廢棄物數值,長期只報告實際數值的一半。

「泊核電站」位於北海道古宇郡泊村,自1988年至2012年間運作。日本北海道電力公司會定期向日本原子能規制廳、北海道政府及泊村等報告放射性氣體廢棄物排放量。不過,該公司在煙囪採集樣本時,一直忽略樣本會因混入空氣而被稀釋一半,結果一直採用錯誤數值。

共同社報導,這是因該公司的操作手冊中,遺漏了需要修正數值的記述。北海道電力公司副社長阪井一郎為事件道歉,但公司稱排放仍未超出安全標準。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置台北網頁設計,各種案例分享

詳解Kafka Producer

上一篇文章我們主要介紹了什麼是 Kafka,Kafka 的基本概念是什麼,Kafka 單機和集群版的搭建,以及對基本的配置文件進行了大致的介紹,還對 Kafka 的幾個主要角色進行了描述,我們知道,不管是把 Kafka 用作消息隊列、消息總線還是數據存儲平台來使用,最終是繞不過消息這個詞的,這也是 Kafka 最最核心的內容,Kafka 的消息從哪裡來?到哪裡去?都干什麼了?別著急,一步一步來,先說說 Kafka 的消息從哪來。

生產者概述

在 Kafka 中,我們把產生消息的那一方稱為生產者,比如我們經常回去淘寶購物,你打開淘寶的那一刻,你的登陸信息,登陸次數都會作為消息傳輸到 Kafka 後台,當你瀏覽購物的時候,你的瀏覽信息,你的搜索指數,你的購物愛好都會作為一個個消息傳遞給 Kafka 後台,然後淘寶會根據你的愛好做智能推薦,致使你的錢包從來都禁不住誘惑,那麼這些生產者產生的消息是怎麼傳到 Kafka 應用程序的呢?發送過程是怎麼樣的呢?

儘管消息的產生非常簡單,但是消息的發送過程還是比較複雜的,如圖

我們從創建一個ProducerRecord 對象開始,ProducerRecord 是 Kafka 中的一個核心類,它代表了一組 Kafka 需要發送的 key/value 鍵值對,它由記錄要發送到的主題名稱(Topic Name),可選的分區號(Partition Number)以及可選的鍵值對構成。

在發送 ProducerRecord 時,我們需要將鍵值對對象由序列化器轉換為字節數組,這樣它們才能夠在網絡上傳輸。然後消息到達了分區器。

如果發送過程中指定了有效的分區號,那麼在發送記錄時將使用該分區。如果發送過程中未指定分區,則將使用key 的 hash 函數映射指定一個分區。如果發送的過程中既沒有分區號也沒有,則將以循環的方式分配一個分區。選好分區后,生產者就知道向哪個主題和分區發送數據了。

ProducerRecord 還有關聯的時間戳,如果用戶沒有提供時間戳,那麼生產者將會在記錄中使用當前的時間作為時間戳。Kafka 最終使用的時間戳取決於 topic 主題配置的時間戳類型。

  • 如果將主題配置為使用 CreateTime,則生產者記錄中的時間戳將由 broker 使用。
  • 如果將主題配置為使用LogAppendTime,則生產者記錄中的時間戳在將消息添加到其日誌中時,將由 broker 重寫。

然後,這條消息被存放在一個記錄批次里,這個批次里的所有消息會被發送到相同的主題和分區上。由一個獨立的線程負責把它們發到 Kafka Broker 上。

Kafka Broker 在收到消息時會返回一個響應,如果寫入成功,會返回一個 RecordMetaData 對象,它包含了主題和分區信息,以及記錄在分區里的偏移量,上面兩種的時間戳類型也會返回給用戶。如果寫入失敗,會返回一個錯誤。生產者在收到錯誤之後會嘗試重新發送消息,幾次之後如果還是失敗的話,就返回錯誤消息。

創建 Kafka 生產者

要往 Kafka 寫入消息,首先需要創建一個生產者對象,並設置一些屬性。Kafka 生產者有3個必選的屬性

  • bootstrap.servers

該屬性指定 broker 的地址清單,地址的格式為 host:port。清單里不需要包含所有的 broker 地址,生產者會從給定的 broker 里查找到其他的 broker 信息。不過建議至少要提供兩個 broker 信息,一旦其中一個宕機,生產者仍然能夠連接到集群上。

  • key.serializer

broker 需要接收到序列化之後的 key/value值,所以生產者發送的消息需要經過序列化之後才傳遞給 Kafka Broker。生產者需要知道採用何種方式把 Java 對象轉換為字節數組。key.serializer 必須被設置為一個實現了org.apache.kafka.common.serialization.Serializer 接口的類,生產者會使用這個類把鍵對象序列化為字節數組。這裏拓展一下 Serializer 類

Serializer 是一個接口,它表示類將會採用何種方式序列化,它的作用是把對象轉換為字節,實現了 Serializer 接口的類主要有 ByteArraySerializerStringSerializerIntegerSerializer ,其中 ByteArraySerialize 是 Kafka 默認使用的序列化器,其他的序列化器還有很多,你可以通過 查看其他序列化器。要注意的一點:key.serializer 是必須要設置的,即使你打算只發送值的內容

  • value.serializer

與 key.serializer 一樣,value.serializer 指定的類會將值序列化。

下面代碼演示了如何創建一個 Kafka 生產者,這裏只指定了必要的屬性,其他使用默認的配置

private Properties properties = new Properties();
properties.put("bootstrap.servers","broker1:9092,broker2:9092");
properties.put("key.serializer","org.apache.kafka.common.serialization.StringSerializer");
properties.put("value.serializer","org.apache.kafka.common.serialization.StringSerializer");
properties = new KafkaProducer<String,String>(properties);

來解釋一下這段代碼

  • 首先創建了一個 Properties 對象
  • 使用 StringSerializer 序列化器序列化 key / value 鍵值對
  • 在這裏我們創建了一個新的生產者對象,併為鍵值設置了恰當的類型,然後把 Properties 對象傳遞給他。

實例化生產者對象后,接下來就可以開始發送消息了,發送消息主要由下面幾種方式

直接發送,不考慮結果

使用這種發送方式,不會關心消息是否到達,會丟失一些消息,因為 Kafka 是高可用的,生產者會自動嘗試重發,這種發送方式和 UDP 運輸層協議很相似。

同步發送

同步發送仍然使用 send() 方法發送消息,它會返回一個 Future 對象,調用 get() 方法進行等待,就可以知道消息時候否發送成功。

異步發送

異步發送指的是我們調用 send() 方法,並制定一個回調函數,服務器在返迴響應時調用該函數。

下一節我們會重新討論這三種實現。

向 Kafka 發送消息

簡單消息發送

Kafka 最簡單的消息發送如下:

ProducerRecord<String,String> record =
                new ProducerRecord<String, String>("CustomerCountry","West","France");

producer.send(record);

代碼中生產者(producer)的 send() 方法需要把 ProducerRecord 的對象作為參數進行發送,ProducerRecord 有很多構造函數,這個我們下面討論,這裏調用的是

public ProducerRecord(String topic, K key, V value) {}

這個構造函數,需要傳遞的是 topic主題,key 和 value。

把對應的參數傳遞完成后,生產者調用 send() 方法發送消息(ProducerRecord對象)。我們可以從生產者的架構圖中看出,消息是先被寫入分區中的緩衝區中,然後分批次發送給 Kafka Broker。

發送成功后,send() 方法會返回一個 Future(java.util.concurrent) 對象,Future 對象的類型是 RecordMetadata 類型,我們上面這段代碼沒有考慮返回值,所以沒有生成對應的 Future 對象,所以沒有辦法知道消息是否發送成功。如果不是很重要的信息或者對結果不會產生影響的信息,可以使用這種方式進行發送。

我們可以忽略發送消息時可能發生的錯誤或者在服務器端可能發生的錯誤,但在消息發送之前,生產者還可能發生其他的異常。這些異常有可能是 SerializationException(序列化失敗)BufferedExhaustedException 或 TimeoutException(說明緩衝區已滿),又或是 InterruptedException(說明發送線程被中斷)

同步發送消息

第二種消息發送機制如下所示

ProducerRecord<String,String> record =
                new ProducerRecord<String, String>("CustomerCountry","West","France");

try{
  RecordMetadata recordMetadata = producer.send(record).get();
}catch(Exception e){
  e.printStackTrace();
}

這種發送消息的方式較上面的發送方式有了改進,首先調用 send() 方法,然後再調用 get() 方法等待 Kafka 響應。如果服務器返回錯誤,get() 方法會拋出異常,如果沒有發生錯誤,我們會得到 RecordMetadata 對象,可以用它來查看消息記錄。

生產者(KafkaProducer)在發送的過程中會出現兩類錯誤:其中一類是重試錯誤,這類錯誤可以通過重發消息來解決。比如連接的錯誤,可以通過再次建立連接來解決;無錯誤則可以通過重新為分區選舉首領來解決。KafkaProducer 被配置為自動重試,如果多次重試后仍無法解決問題,則會拋出重試異常。另一類錯誤是無法通過重試來解決的,比如消息過大對於這類錯誤,KafkaProducer 不會進行重試,直接拋出異常。

異步發送消息

同步發送消息都有個問題,那就是同一時間只能有一個消息在發送,這會造成許多消息無法直接發送,造成消息滯后,無法發揮效益最大化。

比如消息在應用程序和 Kafka 集群之間一個來回需要 10ms。如果發送完每個消息后都等待響應的話,那麼發送100個消息需要 1 秒,但是如果是異步方式的話,發送 100 條消息所需要的時間就會少很多很多。大多數時候,雖然Kafka 會返回 RecordMetadata 消息,但是我們並不需要等待響應。

為了在異步發送消息的同時能夠對異常情況進行處理,生產者提供了回掉支持。下面是回調的一個例子

ProducerRecord<String, String> producerRecord = new ProducerRecord<String, String>("CustomerCountry", "Huston", "America");
        producer.send(producerRecord,new DemoProducerCallBack());


class DemoProducerCallBack implements Callback {

  public void onCompletion(RecordMetadata metadata, Exception exception) {
    if(exception != null){
      exception.printStackTrace();;
    }
  }
}

首先實現回調需要定義一個實現了org.apache.kafka.clients.producer.Callback的類,這個接口只有一個 onCompletion方法。如果 kafka 返回一個錯誤,onCompletion 方法會拋出一個非空(non null)異常,這裏我們只是簡單的把它打印出來,如果是生產環境需要更詳細的處理,然後在 send() 方法發送的時候傳遞一個 Callback 回調的對象。

生產者分區機制

Kafka 對於數據的讀寫是以分區為粒度的,分區可以分佈在多個主機(Broker)中,這樣每個節點能夠實現獨立的數據寫入和讀取,並且能夠通過增加新的節點來增加 Kafka 集群的吞吐量,通過分區部署在多個 Broker 來實現負載均衡的效果。

上面我們介紹了生產者的發送方式有三種:不管結果如何直接發送發送並返回結果發送並回調。由於消息是存在主題(topic)的分區(partition)中的,所以當 Producer 生產者發送產生一條消息發給 topic 的時候,你如何判斷這條消息會存在哪個分區中呢?

這其實就設計到 Kafka 的分區機制了。

分區策略

Kafka 的分區策略指的就是將生產者發送到哪個分區的算法。Kafka 為我們提供了默認的分區策略,同時它也支持你自定義分區策略。

如果要自定義分區策略的話,你需要显示配置生產者端的參數 Partitioner.class,我們可以看一下這個類它位於 org.apache.kafka.clients.producer 包下

public interface Partitioner extends Configurable, Closeable {
  
  public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);

  public void close();
  
  default public void onNewBatch(String topic, Cluster cluster, int prevPartition) {}
}

Partitioner 類有三個方法,分別來解釋一下

  • partition(): 這個類有幾個參數: topic,表示需要傳遞的主題;key 表示消息中的鍵值;keyBytes表示分區中序列化過後的key,byte數組的形式傳遞;value 表示消息的 value 值;valueBytes 表示分區中序列化后的值數組;cluster表示當前集群的原數據。Kafka 給你這麼多信息,就是希望讓你能夠充分地利用這些信息對消息進行分區,計算出它要被發送到哪個分區中。
  • close() : 繼承了 Closeable 接口能夠實現 close() 方法,在分區關閉時調用。
  • onNewBatch(): 表示通知分區程序用來創建新的批次

其中與分區策略息息相關的就是 partition() 方法了,分區策略有下面這幾種

順序輪訓

順序分配,消息是均勻的分配給每個 partition,即每個分區存儲一次消息。就像下面這樣

上圖表示的就是輪訓策略,輪訓策略是 Kafka Producer 提供的默認策略,如果你不使用指定的輪訓策略的話,Kafka 默認會使用順序輪訓策略的方式。

隨機輪訓

隨機輪訓簡而言之就是隨機的向 partition 中保存消息,如下圖所示

實現隨機分配的代碼只需要兩行,如下

List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
return ThreadLocalRandom.current().nextInt(partitions.size());

先計算出該主題總的分區數,然後隨機地返回一個小於它的正整數。

本質上看隨機策略也是力求將數據均勻地打散到各個分區,但從實際表現來看,它要遜於輪詢策略,所以如果追求數據的均勻分佈,還是使用輪詢策略比較好。事實上,隨機策略是老版本生產者使用的分區策略,在新版本中已經改為輪詢了。

按照 key 進行消息保存

這個策略也叫做 key-ordering 策略,Kafka 中每條消息都會有自己的key,一旦消息被定義了 Key,那麼你就可以保證同一個 Key 的所有消息都進入到相同的分區裏面,由於每個分區下的消息處理都是有順序的,故這個策略被稱為按消息鍵保序策略,如下圖所示

實現這個策略的 partition 方法同樣簡單,只需要下面兩行代碼即可:

List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
return Math.abs(key.hashCode()) % partitions.size();

上面這幾種分區策略都是比較基礎的策略,除此之外,你還可以自定義分區策略。

生產者壓縮機制

壓縮一詞簡單來講就是一種互換思想,它是一種經典的用 CPU 時間去換磁盤空間或者 I/O 傳輸量的思想,希望以較小的 CPU 開銷帶來更少的磁盤佔用或更少的網絡 I/O 傳輸。如果你還不了解的話我希望你先讀完這篇文章 ,然後你就明白壓縮是怎麼回事了。

Kafka 壓縮是什麼

Kafka 的消息分為兩層:消息集合 和 消息。一個消息集合中包含若干條日誌項,而日誌項才是真正封裝消息的地方。Kafka 底層的消息日誌由一系列消息集合日誌項組成。Kafka 通常不會直接操作具體的一條條消息,它總是在消息集合這個層面上進行寫入操作。

在 Kafka 中,壓縮會發生在兩個地方:Kafka Producer 和 Kafka Consumer,為什麼啟用壓縮?說白了就是消息太大,需要變小一點 來使消息發的更快一些。

Kafka Producer 中使用 compression.type 來開啟壓縮

private Properties properties = new Properties();
properties.put("bootstrap.servers","192.168.1.9:9092");
properties.put("key.serializer","org.apache.kafka.common.serialization.StringSerializer");
properties.put("value.serializer","org.apache.kafka.common.serialization.StringSerializer");
properties.put("compression.type", "gzip");

Producer<String,String> producer = new KafkaProducer<String, String>(properties);

ProducerRecord<String,String> record =
  new ProducerRecord<String, String>("CustomerCountry","Precision Products","France");

上面代碼錶明該 Producer 的壓縮算法使用的是 GZIP

有壓縮必有解壓縮,Producer 使用壓縮算法壓縮消息后併發送給服務器后,由 Consumer 消費者進行解壓縮,因為採用的何種壓縮算法是隨着 key、value 一起發送過去的,所以消費者知道採用何種壓縮算法。

Kafka 重要參數配置

在上一篇文章 中,我們主要介紹了一下 kafka 集群搭建的參數,本篇文章我們來介紹一下 Kafka 生產者重要的配置,生產者有很多可配置的參數,在文檔里(

key.serializer

用於 key 鍵的序列化,它實現了 org.apache.kafka.common.serialization.Serializer 接口

value.serializer

用於 value 值的序列化,實現了 org.apache.kafka.common.serialization.Serializer 接口

acks

acks 參數指定了要有多少個分區副本接收消息,生產者才認為消息是寫入成功的。此參數對消息丟失的影響較大

  • 如果 acks = 0,就表示生產者也不知道自己產生的消息是否被服務器接收了,它才知道它寫成功了。如果發送的途中產生了錯誤,生產者也不知道,它也比較懵逼,因為沒有返回任何消息。這就類似於 UDP 的運輸層協議,只管發,服務器接受不接受它也不關心。
  • 如果 acks = 1,只要集群的 Leader 接收到消息,就會給生產者返回一條消息,告訴它寫入成功。如果發送途中造成了網絡異常或者 Leader 還沒選舉出來等其他情況導致消息寫入失敗,生產者會受到錯誤消息,這時候生產者往往會再次重發數據。因為消息的發送也分為 同步異步,Kafka 為了保證消息的高效傳輸會決定是同步發送還是異步發送。如果讓客戶端等待服務器的響應(通過調用 Future 中的 get() 方法),顯然會增加延遲,如果客戶端使用回調,就會解決這個問題。
  • 如果 acks = all,這種情況下是只有當所有參与複製的節點都收到消息時,生產者才會接收到一個來自服務器的消息。不過,它的延遲比 acks =1 時更高,因為我們要等待不只一個服務器節點接收消息。

buffer.memory

此參數用來設置生產者內存緩衝區的大小,生產者用它緩衝要發送到服務器的消息。如果應用程序發送消息的速度超過發送到服務器的速度,會導致生產者空間不足。這個時候,send() 方法調用要麼被阻塞,要麼拋出異常,具體取決於 block.on.buffer.null 參數的設置。

compression.type

此參數來表示生產者啟用何種壓縮算法,默認情況下,消息發送時不會被壓縮。該參數可以設置為 snappy、gzip 和 lz4,它指定了消息發送給 broker 之前使用哪一種壓縮算法進行壓縮。下面是各壓縮算法的對比

retries

生產者從服務器收到的錯誤有可能是臨時性的錯誤(比如分區找不到首領),在這種情況下,reteis 參數的值決定了生產者可以重發的消息次數,如果達到這個次數,生產者會放棄重試並返回錯誤。默認情況下,生產者在每次重試之間等待 100ms,這個等待參數可以通過 retry.backoff.ms 進行修改。

batch.size

當有多個消息需要被發送到同一個分區時,生產者會把它們放在同一個批次里。該參數指定了一個批次可以使用的內存大小,按照字節數計算。當批次被填滿,批次里的所有消息會被發送出去。不過生產者井不一定都會等到批次被填滿才發送,任意條數的消息都可能被發送。

client.id

此參數可以是任意的字符串,服務器會用它來識別消息的來源,一般配置在日誌里

max.in.flight.requests.per.connection

此參數指定了生產者在收到服務器響應之前可以發送多少消息,它的值越高,就會佔用越多的內存,不過也會提高吞吐量。把它設為1 可以保證消息是按照發送的順序寫入服務器。

timeout.ms、request.timeout.ms 和 metadata.fetch.timeout.ms

request.timeout.ms 指定了生產者在發送數據時等待服務器返回的響應時間,metadata.fetch.timeout.ms 指定了生產者在獲取元數據(比如目標分區的首領是誰)時等待服務器返迴響應的時間。如果等待時間超時,生產者要麼重試發送數據,要麼返回一個錯誤。timeout.ms 指定了 broker 等待同步副本返回消息確認的時間,與 asks 的配置相匹配—-如果在指定時間內沒有收到同步副本的確認,那麼 broker 就會返回一個錯誤。

max.block.ms

此參數指定了在調用 send() 方法或使用 partitionFor() 方法獲取元數據時生產者的阻塞時間當生產者的發送緩衝區已捕,或者沒有可用的元數據時,這些方法就會阻塞。在阻塞時間達到 max.block.ms 時,生產者會拋出超時異常。

max.request.size

該參數用於控制生產者發送的請求大小。它可以指能發送的單個消息的最大值,也可以指單個請求里所有消息的總大小。

receive.buffer.bytes 和 send.buffer.bytes

Kafka 是基於 TCP 實現的,為了保證可靠的消息傳輸,這兩個參數分別指定了 TCP Socket 接收和發送數據包的緩衝區的大小。如果它們被設置為 -1,就使用操作系統的默認值。如果生產者或消費者與 broker 處於不同的數據中心,那麼可以適當增大這些值。

文章參考:

《Kafka 權威指南》

極客時間 -《Kafka 核心技術與實戰》

Kafka 源碼

關注公眾號獲取更多優質电子書,關注一下你就知道資源是有多好了

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

「巴逢」平安夜登陸菲律賓 至少1死6失蹤

摘錄自2019年12月26日公視報導

昨(25日)耶誕節,台灣各地都有25度以上,度過一個溫暖的耶誕。鄰國菲律賓卻碰上罕見的冬颱攪局,颱風巴逢在平安夜這天登陸菲律賓中部,讓當地大批人民度過溼答答又驚恐的節日,還造成至少一人死亡、六人失蹤。

強風伴隨著大雨,巴逢颱風在平安夜登陸菲律賓中部,街道上水淹及膝,路上車輛和行人勉強涉水而過。耶誕佳節碰到罕見的冬颱攪局,風強雨大,瞬間最大陣風來到時速195公里,強勁的風勢把民宅鐵皮屋頂掀飛,飼養的牛隻也無法倖免於難。

維修人員冒險爬上傾斜的電線桿,希望能盡快恢復供電。菲律賓當局指出,有超過1萬6千人被迫在避難所度過平安夜,還有2萬5千多人無法搭上渡輪回家團圓。菲律賓中部各地,累積雨量普遍超過100毫米,部份地區甚至多達200多毫米。根據美國有線電視新聞網CNN報導,巴逢颱風至少造成一人死亡,還有六人被大水沖走,下落不明。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

建立通用MRV機制 讓碳排計算公平且透明

文:范馨心(InnoEnergy永續能源工程與管理碩士學程)

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置台北網頁設計,各種案例分享

廣汽將與樂視聯手打造互聯網生態圈

6月6日晚間,廣汽集團正式發佈公告稱,公司董事會審議並通過了《關於調整廣汽集團汽車互聯網生態圈專案的議案》。公告正式公佈了廣汽集團汽車互聯網生態圈專案將由廣州汽車集團股份有限公司、樂視控股(北京)有限公司及眾誠汽車保險股份有限公司共同出資,三方股比分別為45%、40%和15%。

事實上,早在公告發佈之前,樂視與廣汽就各自在汽車電商方面有著完整的規劃與佈局。在不久之前的北京車展上,樂視超級汽車聯合創始人,全球副董事長丁磊就曾透露,樂視將於近期與國內一家一流汽車集團開展汽車電商方面的合作,探索全新的生態電商模式。而樂視生態O2O高級副總裁、樂視商城負責人趙一成也在發佈會上表示,樂視商城將進軍汽車領域,打造全球首家生態型O2O汽車電商。

廣汽集團在2015年7月已經宣佈將啟動汽車互聯網生態圈專案的實施,建設包括整車電商平臺、車生活平臺、車聯網平臺和創業投融資平臺等四個平臺。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

特斯拉上海工廠獲當局協助,預計 2/10 復工

電動車龍頭特斯拉(Tesla)股價近期出現戲劇性走勢,3、4 日連續兩天以 2 位數速度暴漲,5 日則受中國交車進度料延遲的消息影響,股價重挫逾 17%。不過,中國官員 8 日表示,將盡全力協助企業復工,特斯拉上海工廠將於 10 日恢復生產。

路透社 8 日報導,中國各地工廠的農曆新年假期停工時間,原定 1 月 30 日結束,但由於新型冠狀病毒肺炎疫情嚴峻,中國政府緊急要求企業及工廠延長停工至 2 月 9 日,以防堵疫情擴散。

2 月 4 日,特斯拉全球副總裁陶琳在個人微博表示,原定春節後 2 月初的交車計畫將會暫緩,疫情好轉後會盡力補上交車進度。受此消息影響,5 日特斯拉股價大跌 17.18%,創公司史上第二高單日跌幅,僅次 2012 年 1 月 13 日的 19.33%。

對此,上海市人民政府新聞發言人徐威表示,針對特斯拉等重點企業在復工過程遇到的實際困難,當局將盡全力協調,幫助企業儘快恢復正常生產。

報導指出,特斯拉上海工廠耗資 20 億美元,是特斯拉旗下首座海外工廠,受中國政府大力支持。工廠去年 10 月開始生產,並於今年 1 月舉辦首批中國製 Model 3 交車儀式。

7 日特斯拉股價下跌 0.12%,收 748.07 美元。3 日及 4 日,特斯拉股價分別飆漲 19.89%、13.73%,使股價衝上 887.06 美元,但隨後回吐漲幅,5 日重挫 17.18% 至 734.70 美元。

光 2020 年初以來,特斯拉股價已瘋狂上漲 78.82%,但也引來泡沫效應的疑慮聲浪。CNBC 8 日報導,據 FactSet 數據,目前約 45% 華爾街分析師給予特斯拉股票「賣出」評級,比率創歷來新高,僅 19% 分析師給予「買進」評級,「持有」評級則佔 36%。

券商 Needham 分析師 Rajvindra Gill 5 日出具研究報告,對特斯拉給出「遜於大盤」評級。他指出,從未見過股價上漲如此快速,投資人對過去基本面或成長紀錄卻鮮少關注的現象,反映特斯拉股票的「非理性繁榮」(Irrational exuberance)達到歷史新高。

(本文內文由  授權使用;首圖來源:)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置台北網頁設計,各種案例分享

JVM 中你不得不知的一些參數

有的同學雖然寫了一段時間 Java 了,但是對於 JVM 卻不太關注。有的同學說,參數都是團隊規定好的,部署的時候也不用我動手,關注它有什麼用,而且,JVM 這東西,聽上去就感覺很神秘很高深的樣子,還是算了吧。

沒錯,部署的時候可能用不到你親自動手,但是出現問題了怎麼辦,難道不用你解決問題嗎,如果對 JVM 了解不夠的話,有些問題可能排查起來就很費力,或者根本無法解決。

本篇以 JDK Hotspot 8 為背景,介紹一下 JVM 的常用參數。建議你在做一些小項目、小 demo 的時候,也把這些參數加上,加深印象。以我的經驗來看,有些知識你剛開始接觸的時候會感覺很難理解,但是沒關係,萬事開頭難嘛,知識點都是需要消化時間的。第一天不理解,甚至過了一個月也不理解,但是總有那麼一刻,你會突然有種茅塞頓開的感覺,感覺一下子通了。最後心裏面感謝自己在多少多少天以前能夠開始學習並堅持學習這些知識點。

只介紹一些常用參數,除了這些常用參數外,Hotspot 還提供了很多其他的參數,每一個都值得考究。

在使用這些參數之前,你需要對 Java 內存模型有一定的了解,可以讀一下 了解一下內存模型。

還是要把內存模型圖放在這裏,方便理解。

堆參數:

-Xms: 堆的初始值,例如 -Xmx2048,初始堆大小為 2G

-Xmx: 堆的最大值,例如 -Xmx2048M,允許最大堆內存 2G

-Xmn: 新生代大小

-XX:SurvivorRatio:Eden 區所佔比例,默認是 8,也就是 80%,例如 -XX:SurvivorRatio=8

最好將 -Xms 和 -Xmx 的值設置成一樣的值,這樣做是為了防止隨着堆空間使用量增加,會動態的調整堆空間大小,有一定的性能損耗,不如開始就設置成相同的值,來規避性能損失。

棧參數

-Xss:棧空間大小,棧是線程獨佔的,所以是一個線程使用棧空間的大小,例如 -Xss256K,如果不設置此參數,默認值是 1M,一般來講設置成 256K 就足夠了。

Metaspace 參數

-XX:MetaspaceSize:Metaspace 空間初始大小,如果不設置的話,默認是20.79M,這個初始大小是觸發首次 Metaspace Full GC 的閾值,例如 -XX:MetaspaceSize=256M

-XX:MaxMetaspaceSize:Metaspace 最大值,默認不限制大小,但是線上環境建議設置,例如

-XX:MaxMetaspaceSize=256M

-XX:MinMetaspaceFreeRatio:最小空閑比,當 Metaspace 發生 GC 后,會計算 Metaspace 的空閑比,如果空閑比(空閑空間/當前 Metaspace 大小)小於此值,就會觸發 Metaspace 擴容。默認值是 40 ,也就是 40%,例如 -XX:MinMetaspaceFreeRatio=40

-XX:MaxMetaspaceFreeRatio:最大空閑比,當 Metaspace 發生 GC 后,會計算 Metaspace 的空閑比,如果空閑比(空閑空間/當前 Metaspace 大小)大於此值,就會觸發 Metaspace 釋放空間。默認值是 70 ,也就是 70%,例如 -XX:MaxMetaspaceFreeRatio=70

建議將 MetaspaceSize 和 MaxMetaspaceSize 設置為同樣大小,避免頻繁擴容。

GC 日誌

簡單日誌

-verbose:gc 或者 -XX:+PrintGC

日誌格式:

[GC (Allocation Failure)  7892K->5646K(19456K), 0.0060442 secs]
[GC (Allocation Failure) , 0.0066315 secs]
[Full GC (Allocation Failure)  19302K->13646K(19456K), 0.0032698 secs]

詳細日誌

#打印詳細日誌
-XX:+PrintGCDetails
#打印 GC 的時間點
-XX:+PrintGCDateStamps

日誌格式:

2019-11-13T14:06:46.099-0800: [GC (Allocation Failure) 2019-11-13T14:06:46.099-0800: [DefNew (promotion failed) : 9180K->9157K(9216K), 0.0084297 secs]2019-11-13T14:06:46.107-0800: [Tenured: 10145K->10145K(10240K), 0.0035768 secs] 13802K->13646K(19456K), [Metaspace: 3895K->3895K(1056768K)], 0.0120887 secs] [Times: user=0.00 sys=0.00, real=0.02 secs] 
2019-11-13T14:06:47.243-0800: [Full GC (Allocation Failure) 2019-11-13T14:06:47.244-0800: [Tenured: 10145K->10145K(10240K), 0.0042686 secs] 19304K->19146K(19456K), [Metaspace: 3895K->3895K(1056768K)], 0.0043232 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 

以下幾個 GC 日誌相關的參數打印的內容比較多,生產環境可選擇性開啟,大多數時候不需要開啟。

GC 前後的堆信息

-XX:+PrintHeapAtGC

{Heap before GC invocations=0 (full 0):
 def new generation   total 9216K, used 7892K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
  eden space 8192K,  96% used [0x00000007bec00000, 0x00000007bf3b5200, 
  xxx....
  class space    used 445K, capacity 462K, committed 512K, reserved 1048576K
Heap after GC invocations=1 (full 0):
 def new generation   total 9216K, used 1023K [0x00000007bec00000,
 xxx...
 Metaspace       used 3892K, capacity 4646K, committed 4864K, reserved 1056768K
  class space    used 445K, capacity 462K, committed 512K, reserved 1048576K
}

GC 導致的 Stop the world 時間

-XX:+PrintGCApplicationStoppedTime

Total time for which application threads were stopped: 0.0070384 seconds, Stopping threads took: 0.0000200 seconds

加載類信息

-verbose:class

[Loaded java.net.URLClassLoader$3$1 from /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/lib/rt.jar]

GC 前後的類加載情況

-XX:+PrintClassHistogramBeforeFullGC
-XX:+PrintClassHistogramAfterFullGC
 num     #instances         #bytes  class name
----------------------------------------------
   1:           140       19016264  [B
   2:          2853         226256  [C
   3:           138         169072  [I
   4:           761          86240  java.lang.Class
   5:          2850          68400  java.lang.String
   6:           660          41024  [Ljava.lang.Object;

日誌輸出到文件

以上參數配置好之後,默認會輸出到控制台或者服務指定的統一日誌的位置。但是這裏還會有服務的一般性信息日誌、錯誤日誌等,都混在一起的話會比較亂,所以,一般都會把 jvm 日誌單獨存放。

#GC 活動日誌,根據配置的參數輸出內容
-Xloggc:/Users/fengzheng/jvmlog/gc.log

#致命錯誤日誌,只有在 jvm 發生崩潰的時候會輸出
-XX:ErrorFile=/Users/fengzheng/jvmlog/hs_err_pid%p.log

堆溢出現場保留

有些錯誤雖然不會導致 jvm 崩潰,但是對於服務而言也是非常嚴重的,比如stackOverflow、OutOfMemoryError,發生錯誤后,留存現場信息對分析錯誤原因是至關重要的。jvm 提供了保留堆溢出現場的方法,對於 JDK 8 而言,可能是 heap 溢出,也可能是 Metasapce 溢出。

-XX:HeapDumpPath=/Users/fengzheng/jvmlog
-XX:+HeapDumpOnOutOfMemoryError

最後出現異常后,保存的文件格式為 java_pidxxx.hprof,pid 後面是發生溢出的進程 id,之後可以用 VisualVM、JProfiler 等工具打開分析。

設置垃圾回收器類型

隨着 JDK 版本的升級,可使用的垃圾收集器類型也越來越多了。JDK 8 可使用的垃圾收集器有 7 種,當然有點只適用於年輕代,有點只使用於老年代,JDK 8 中最新的垃圾收集器是 G1,可以用於年輕代和老年代。到了 JDK 11,還出了 ZGC。

下圖是 JDK 8 中可使用的垃圾收集器以及它們配合使用的關係。

Serial、ParNew、Parallel Scavenge 只適用於年輕代,CMS、Serial Old、Parallel Old 只適用於老年代,而 G1 通用於年輕代和老年代。連線表示它們之間可配合使用的關係,其中 CMS 和 Serial Old 連線的意思是說 Serial Old 會作為 CMS 的后預案,當 CMS 發生 Concurrent Mode Failure 時啟用。

在 JDK 8 中,如果不指定垃圾收集器,默認使用參數 -XX:+UseParallelGC,新生代使用 Parallel Scavenge,老年代使用 Serial Old。

-XX:+UseSerialGC:使用 Serial + Serial Old ,運行於 client 模式下的默認設置

-XX:+UseConcMarkSweepGC:使用 ParNew+CMS+Serial Old,CMS 垃圾收集器

-XX:+UseParallelGC:Parallel Scavenge + Serial Old,JDK 8 server 模式下的默認設置

-XX:+UseParallelOldGC:Parallel Scavenge + Parallel Old

-XX:+UseG1GC:使用 G1 垃圾收集器

開啟遠程 JMX 監控

除了日誌外,當我們需要實時查看 JVM 運行情況的時候怎麼辦,當然可以到 JVM 所在服務器用 jstack、jmap、jinfo 等工具進行查看,但是又不夠直觀,這時候就需要開啟 JMX 遠程功能,使用 jConsole、VisualVM 等工具進行監控。或者自己開發監控平台,比如我之前就做了一個 web 版的簡易 VisualVm。

開啟參數如下:

-Dcom.sun.management.jmxremote
#指定 jvm 所在服務器 ip 或域名
-Djava.rmi.server.hostname=192.168.1.1
#指定端口
-Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.rmi.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
相關閱讀:

不要吝惜你的「推薦」呦

歡迎關注,不定期更新本系列和其他文章
古時的風箏 ,進入公眾號可以加入交流群

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

「每日五分鐘,玩轉 JVM」:GC 概覽

前言

GC(Garbage Collection)是我們在學習 JVM 的過程中不可避免的一道坎,接下來,我們就來系統的學習一下 GC。

做一件事情之前,我們一定要去知道我們為什麼要去做,這裏不僅僅指 GC,更適用我們日常的學習和生活,知其然,知其所以然,方能百戰不殆。

下面我們先去了解為什麼要有 GC,以及 GC 在 JVM 中扮演了一個什麼樣的角色,起到了什麼的作用?

為什麼要有 GC

用過 C++ 的同學可能知道,對象所佔的內存在程序結束運行之前一直被佔用,在明確釋放之前不能分配給其它對象。如果我們不去手動的清除這些無用的對象,內存很快就被佔滿,而在 JVM 中,GC 所起到的作用就是一個清道夫,它可以幫助我們去判定哪些對象是無用對象怎麼進行垃圾收集,以及決定內存分代和內存分配的策略**。

可能有同學會問了,既然我們的 JVM 會給我們做 GC 的工作,我們為什麼還要去學習 GC 呢,一切交給 JVM 不好嗎?當然,在我們的日常情況下,我們一般不會去關心 GC 的一些細節,但是當我們遇到內存泄露,內存溢出,高併發瓶頸的時候,我們就需要去對 GC 開刀,進行更為細緻的監控和調節。

內存泄露:指程序中己動態分配的堆內存由於某種原因程序未釋放或無法釋放,造成系統內存的浪費,導致程序運行速度減慢甚至系統崩潰等嚴重後果。

內存溢出:應用系統中存在無法回收的內存或使用的內存過多,最終使得程序運行要用到的內存大於能提供的最大內存。

那麼現在問題來了,我們要進行垃圾回收,首先我們需要知道垃圾在哪

垃圾在哪

前面我們講了JVM 的運行時內存區域,知道線程可以分為線程獨佔區和線程共享區,其中線程獨佔區(程序計數器,虛擬機棧,本地方法棧)的內存生命周期是和線程保持一致,且這幾個區域分配的內存大小跟類的大小有關,也就是說,當我們的類結構固定之後,這部分的內存就不會再發生更改,且當方法或線程結束的時候,內存自然就跟隨着回收了.

而線程共享區的堆內存和方法區則不一樣,堆內存和方法區所用的內存是在編譯期間無法確定的,因為一個接口的不同實現,一個方法的不同控制條件分支所執行的代碼可能完全相反,我們只有在運行時才知道會創建哪些對象,這部分的內存的分配和回收是動態的,而我們的 GC 關注的就是該部分的內存。

打個比方來說:JVM 如果是一輛車,線程獨佔區的就像是零件,在出廠時這些零件的壽命基本上都是已知的,線程共享區就像是汽油,汽油的消耗跟我們所採用的路線有關,所以我們關注的部分就是這部分會動態變化的,比如如何開車才能更省油~

知道了垃圾在什麼位置會出現,我們下一步就需要去判定在這些區域的有哪些是垃圾~

下節預告

本節內容到這裏先告一段落,下一節我們來學習,怎麼去判定是否為垃圾~

公眾號

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置台北網頁設計,各種案例分享