這裏來對Java中的String對象做一個稍微深入的了解。

Java對象實現的演進

String對象是Java中使用最頻繁的對象之一，所以Java開發者們也在不斷地對String對象的實現進行優化，以便提升String對象的性能。

Java6以及之前版本中String對象的屬性

在Java6以及之前版本中，String對象是對char數組進行了封裝實現的對象，其主要有4個成員成員變量，分別是char數組、偏移量offset、字符數量count和哈希值hash。String對象是通過offset和count兩個屬性來定位char[]數組，獲取字符串。這樣做可以高效、快速地共享數組對象，同時節省內存空間，但是這種方式卻可能會導致內存泄漏的發生。

Java7、8版本中String對象的屬性

從Java7版本開始，Java對String類做了一些改變，具體是String類不再有offset和count兩個變量了。這樣做的好處是String對象佔用的內存稍微少了點，同時String.substring()方法也不再共享char[]了，從而解決了使用該方法可能導致的內存泄漏問題。

Java9以及之後版本中String對象的屬性

從Java9版本開始，Java將char[]數組改為了byte[]數組。我們都知道，char是兩個字節的，如果用來存一個字節的情況下就會造成內存空間的浪費。而為了節約這一個字節的空間，Java開發者就改成了一個使用一個字節的byte來存儲字符串。

另外，在Java9中，String對象維護了一個新的屬性coder，這個屬性是編碼格式的標識，在計算字符串長度或者調用indexOf()方法的時候，會需要根據這個字段去判斷如何計算字符串長度。coder屬性默認有0和1兩個值，其中0代表Latin-1（單字節編碼），1則表示UTF-16編碼。

String對象的創建方式與在內存中的存放

在Java中，對於基本數據類型的變量和對對象的引用，保存在棧內存的局部變量表中；而通過new關鍵字和Constructor創建的對象，則是保存在堆內存中。而String對象的創建方式一般為兩種，一種是字面量（字符串常量）的方式，一種則是構造函數（String()）的方式，兩種方式在內存中的存放有所不同。

字面量（字符串常量）的創建方式

使用字面量的方式創建字符串時，JVM會在字符串常量池中先檢查是否存在該字面量，如果存在，則返回該字面量在內存中的引用地址；如果不存在，則在字符串常量池中創建該字面量並返回引用。使用這種方式創建的好處是避免了相同值的字符串在內存中被重複創建，節約了內存，同時這種寫法也會比較簡單易讀一些。

String str = "i like yanggb.";

字符串常量池

這裏要特別說明一下常量池。常量池是JVM為了減少字符串對象的重複創建，特別維護了一個特殊的內存，這段內存被稱為字符串常量池或者字符串字面量池。在JDK1.6以及之前的版本中，運行時常量池是在方法區中的。在JDK1.7以及之後版本的JVM，已經將運行時常量池從方法區中移了出來，在Java堆（Heap）中開闢了一塊區域用來存放運行時常量池。而從JDK1.8開始，JVM取消了Java方法區，取而代之的是位於直接內存的元空間（MetaSpace）。總結就是，目前的字符串常量池在堆中。

我們所知道的幾個String對象的特點都來源於String常量池。

1.在常量池中會共享所有的String對象，因此String對象是不可被修改的，因為一旦被修改，就會導致所有引用此String對象的變量都隨之改變（引用改變），所以String對象是被設計為不可修改的，後面會對這個不可變的特性做一個深入的了解。

2.String對象拼接字符串的性能較差的說法也是來源於此，因為String對象不可變的特性，每次修改（這裡是拼接）都是返回一個新的字符串對象，而不是再原有的字符串對象上做修改，因此創建新的String對象會消耗較多的性能（開闢另外的內存空間）。

3.因為常量池中創建的String對象是共享的，因此使用雙引號聲明的String對象（字面量）會直接存儲在常量池中，如果該字面量在之前已存在，則是會直接引用已存在的String對象，這一點在上面已經描述過了，這裏再次提及，是為了特別說明這一做法保證了在常量池中的每個String對象都是唯一的，也就達到了節約內存的目的。

構造函數（String()）的創建方式

使用構造函數的方式創建字符串時，JVM同樣會在字符串常量池中先檢查是否存在該字面量，只是檢查后的情況會和使用字面量創建的方式有所不同。如果存在，則會在堆中另外創建一個String對象，然後在這個String對象的內部引用該字面量，最後返回該String對象在內存地址中的引用；如果不存在，則會先在字符串常量池中創建該字面量，然後再在堆中創建一個String對象，然後再在這個String對象的內部引用該字面量，最後返回該String對象的引用。

String str = new String("i like yanggb.");

這就意味着，只要使用這種方式，構造函數都會另行在堆內存中開闢空間，創建一個新的String對象。具體的理解是，在字符串常量池中不存在對應的字面量的情況下，new String()會創建兩個對象，一個放入常量池中（字面量），一個放入堆內存中（字符串對象）。

String對象的比較

比較兩個String對象是否相等，通常是有【==】和【equals()】兩個方法。

在基本數據類型中，只可以使用【==】，也就是比較他們的值是否相同；而對於對象（包括String）來說，【==】比較的是地址是否相同，【equals()】才是比較他們內容是否相同；而equals()是Object都擁有的一個函數，本身就要求對內部值進行比較。

String str = "i like yanggb.";
String str1 = new String("i like yanggb.");

System.out.println(str == str1); // false
System.out.println(str.equals(str1)); // true

因為使用字面量方式創建的String對象和使用構造函數方式創建的String對象的內存地址是不同的，但是其中的內容卻是相同的，也就導致了上面的結果。

String對象中的intern()方法

我們都知道，String對象中有很多實用的方法。為什麼其他的方法都不說，這裏要特別說明這個intern()方法呢，因為其中的這個intern()方法最為特殊。它的特殊性在於，這個方法在業務場景中幾乎用不上，它的存在就是在為難程序員的，也可以說是為了幫助程序員了解JVM的內存結構而存在的（？我信你個鬼，你個糟老頭子壞得很）。

/**
* When the intern method is invoked, if the pool already contains a
* string equal to this {@code String} object as determined by
* the {@link #equals(Object)} method, then the string from the pool is
* returned. Otherwise, this {@code String} object is added to the
* pool and a reference to this {@code String} object is returned.
**/
public native String intern();

上面是源碼中的intern()方法的官方註釋說明，大概意思就是intern()方法用來返回常量池中的某字符串，如果常量池中已經存在該字符串，則直接返回常量池中該對象的引用。否則，在常量池中加入該對象，然後返回引用。然後我們可以從方法簽名上看出intern()方法是一個native方法。

下面通過幾個例子來詳細了解下intern()方法的用法。

第一個例子

String str1 = new String("1");
System.out.println(str1 == str1.intern()); // false
System.out.println(str1 == "1"); // false

在上面的例子中，intern()方法返回的是常量池中的引用，而str1保存的是堆中對象的引用，因此兩個打印語句的結果都是false。

第二個例子

String str2 = new String("2") + new String("3");
System.out.println(str2 == str2.intern()); // true
System.out.println(str2 == "23"); // true

在上面的例子中，str2保存的是堆中一個String對象的引用，這和JVM對【+】的優化有關。實際上，在給str2賦值的第一條語句中，創建了3個對象，分別是在字符串常量池中創建的2和3、還有在堆中創建的字符串對象23。因為字符串常量池中不存在字符串對象23，所以這裏要特別注意：intern()方法在將堆中存在的字符串對象加入常量池的時候採取了一種截然不同的處理方案——不是在常量池中建立字面量，而是直接將該String對象自身的引用複製到常量池中，即常量池中保存的是堆中已存在的字符串對象的引用。根據前面的說法，這時候調用intern()方法，就會在字符串常量池中複製出一個對堆中已存在的字符串常量的引用，然後返回對字符串常量池中這個對堆中已存在的字符串常量池的引用的引用（就是那麼繞，你來咬我呀）。這樣，在調用intern()方法結束之後，返回結果的就是對堆中該String對象的引用，這時候使用【==】去比較，返回的結果就是true了。同樣的，常量池中的字面量23也不是真正意義的字面量23了，它真正的身份是堆中的那個String對象23。這樣的話，使用【==】去比較字面量23和str2，結果也就是true了。

第三個例子

String str4 = "45";
String str3 = new String("4") + new String("5");
System.out.println(str3 == str3.intern()); // false
System.out.println(str3 == "45"); // false

這個例子乍然看起來好像比前面的例子還要複雜，實際上卻和上面的第一個例子是一樣的，最難理解的反而是第二個例子。

所以這裏就不多說了，而至於為什麼還要舉這個例子，我相信聰明的你一下子就明白了（我有醫保，你來打我呀）。

String對象的不可變性

先來看String對象的一段源碼。

public final class String
    implements java.io.Serializable, Comparable<String>, CharSequence {
    /** The value is used for character storage. */
    private final char value[];

    /** Cache the hash code for the string */
    private int hash; // Default to 0

    /** use serialVersionUID from JDK 1.0.2 for interoperability */
    private static final long serialVersionUID = -6849794470754667710L;
}

從類簽名上來看，String類用了final修飾符，這就意味着這個類是不能被繼承的，這是決定String對象不可變特性的第一點。從類中的數組char[] value來看，這個類成員變量被private和final修飾符修飾，這就意味着其數值一旦被初始化之後就不能再被更改了，這是決定String對象不可變特性的第二點。

Java開發者為什麼要將String對象設置為不可變的，主要可以從以下三個方面去考慮：

1.安全性。假設String對象是可變的，那麼String對象將可能被惡意修改。

2.唯一性。這個做法可以保證hash屬性值不會頻繁變更，也就確保了唯一性，使得類似HashMap的容器才能實現相應的key-value緩存功能。

3.功能性。可以實現字符串常量池（究竟是先有設計，還是先有實現呢）。

String對象的優化

字符串是常用的Java類型之一，所以對字符串的操作是避免不了的。而在對字符串的操作過程中，如果使用不當的話，性能可能會有天差地別，所以有一些地方是要注意一下的。

拼接字符串的性能優化

字符串的拼接是對字符串的操作中最頻繁的一個使用。由於我們都知道了String對象的不可變性，所以我們在開發過程中要盡量減少使用【+】進行字符串拼接操作。這是因為使用【+】進行字符串拼接，會在得到最終想要的結果前產生很多無用的對象。

String str = 'i';
str = str + ' ';
str = str + 'like';
str = str + ' ';
str = str + 'yanggb';
str = str + '.';

System.out.println(str); // i like yanggb.

事實上，如果我們使用的是比較智能的IDE編寫代碼的話，編譯器是會提示將代碼優化成使用StringBuilder或者StringBuffer對象來優化字符串的拼接性能的，因為StringBuilder和StringBuffer都是可變對象，也就避免了過程中產生無用的對象了。而這兩種替代方案的區別是，在需要線程安全的情況下，選用StringBuffer對象，這個對象是支持線程安全的；而在不需要線程安全的情況下，選用StringBuilder對象，因為StringBuilder對象的性能在這種場景下，要比StringBuffer對象或String對象要好得多。

使用intern()方法優化內存佔用

前面吐槽了intern()方法在實際開發中沒什麼用，這裏又來說使用intern()方法來優化內存佔用了，這人真的是，嘿嘿，真香。關於方法的使用就不說了，上面有詳盡的用法說明，這裏來說說具體的應用場景好了。有一位Twitter的工程師在Qcon全球軟件開發大會上分享了一個他們對String對象優化的案例，他們利用了這個String.intern()方法將以前需要20G內存存儲優化到只需要幾百兆內存。具體就是，使用intern()方法將原本需要創建到堆內存中的String對象都放到常量池中，因為常量池的不重複特性（存在則返回引用），也就避免了大量的重複String對象造成的內存浪費問題。

什麼，要我給intern()方法道歉？不可能。String.intern()方法雖好，但是也是需要結合場景來使用的，並不能夠亂用。因為實際上，常量池的實現是類似於一個HashTable的實現方式，而HashTable存儲的數據越大，遍歷的時間複雜度就會增加。這就意味着，如果數據過大的話，整個字符串常量池的負擔就會大大增加，有可能性能不會得到提升卻反而有所下降。

字符串分割的性能優化

字符串的分割是字符串操作的常用操作之一，對於字符串的分割，大部分人使用的都是split()方法，split()方法在大部分場景下接收的參數都是正則表達式，這種分割方式本身沒有什麼問題，但是由於正則表達式的性能是非常不穩定的，使用不恰當的話可能會引起回溯問題並導致CPU的佔用居高不下。在以下兩種情況下split()方法不會使用正則表達式：

1.傳入的參數長度為1，且不包含“.$|()[{^?*+\”regex元字符的情況下，不會使用正則表達式。

2.傳入的參數長度為2，第一個字符是反斜杠，並且第二個字符不是ASCII数字或ASCII字母的情況下，不會使用正則表達式。

所以我們在字符串分割時，應該慎重使用split()方法，而首先考慮使用String.indexOf()方法來進行字符串分割，在String.indexOf()無法滿足分割要求的時候再使用Split()方法。而在使用split()方法分割字符串時，需要格外注意回溯問題。

總結

雖然說在不了解String對象的情況下也能使用String對象進行開發，但是了解String對象可以幫助我們寫出更好的代碼。

“只希望在故事的最後，我還是我，你也還是你。”

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

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

閱讀也花了較長的時間，大致也了解到整潔的架構要做到以下兩點：

• well-isolated components：component是獨立部署的最小單元，由一系列遵循SOLID原則的module按照REP、CCP、CEP原則組成。
• dependency rule：低層的detail去依賴高層的police

但感覺並沒有對架構設計給出可行的參考。

clean architecture 中的架構實例

在的第34章 “The Missing Chapter”（由 Simon Brown 編寫）給出了一個具體的案例，用四種架構設計來實現一個 “online book store”。

package by layer

這是最常見的方案，從前往後分為：前端、後台（business logic）、持久化DB。

優點是：簡單、容易上手，符合大多數公司的組織架構。

存在的問題：

• 軟件規模和複雜度增加時，三層架構就不夠了，需要重新考慮拆分；
• 分層架構體現不出business domain；

PACKAGE BY FEATURE

垂直切分方案，所有的java代碼都放在一個package裏面

好處在於凸顯domain concept

PORTS AND ADAPTERS

clean architecture這本書推薦的方案, 外層依賴於內層的domain

PACKAGE BY COMPONENT

本章作者 Simon Brown 提出的方案，service-centric view，將所有相關的職責打包稱一個粗粒度的Jar包

bundling all of the responsibilities related to a single coarse-grained component into a single Java package

看起來類似現在微服務的部署方式

對於以上四種結構，依賴關係看起來是這樣的

值得注意的是

• 虛線箭頭表示component之間的依賴關係
• PORTS AND ADAPTERS這種架構更能體現domain（business logic），即接口命名為Orders而不是OrdersRepository

本章的作者最後還指出：++不管架構怎麼設計，粗心的implementation都可能違背最初的設計；依賴編譯器來保證架構的一以貫之，而不是自我約束或者事後檢查。++

五種常見架構模式

看完了clean architecture后，在網上搜索架構設計相關的書籍，發現了這本小冊子，篇幅很短，稱不上book，而是一個report。

指出缺乏架構設計的軟件往往高度耦合，難以改變。因此，這本小冊子的目標就是介紹常用架構模式的特點、優點、缺點，幫助我們針對特定的業務需求做出合適的選擇。

Layered Architecture

分層架構也稱為n-tire architecture，這是最為常見的一種架構模式，一般從前往後分為四層：presentation, business, persistence, and database。如下圖所示：

分層架構一般是一個新系統的最佳首選，因為其完美匹配傳統IT公司組織架構：一般的公司招人都是前端、後端、數據庫。

分層架構的優點在於關注點隔離（separation of concerns），每一層做好自己這一層的職責，並向上一層提供服務即可，最為經典的案例就是七層網絡模型，這有利於開發、測試、管理與維護。

分層架構中，需要注意的是兩個概念：closed layer、open layer

closed layer的核心就是不要越層訪問，比如在上圖中，Presentation Layer就不應該跨國Business Layer直接去Persistence Layer訪問數據。

A closed layer means that as a request moves from layer to layer, it must go through the layer right below it to get to the next layer below that one

closed layer保證了層隔離（ layers of isolation），使得某一層的修改影響的範圍盡可能小，比較可控。但closed layer有時候也會帶來一個問題：architecture sinkhole anti pattern（污水池反模式），具體是指，為了查簡單數據，層層轉發請求。比如為了在展示層显示玩家的某個數據，需要通過業務層、再到持久化層、再到DB層；取到數據再一層層傳遞迴來，在這個過程中，業務層並沒有對數據有邏輯上的處理。

显示，污水池反模式衝擊了closed layer的美好想法。如何衡量這種層層轉發的請求是不是問題，可以參考80-20法則。

如果80%是附帶邏輯的，那麼就是ok的，但如果有80% 是 simple passthrough processing，那麼就得考慮讓某些layer open。比如在複雜的業務系統中, 經常會有一些可復用的邏輯，這個時候會抽取為通用的服務層(service layer)。如下圖所示

open layer 、close layer的概念可以幫助理清楚架構和請求流程之間的關係，讓架構師、程序員都清楚架構的邊界（boundary）在哪裡，重要的是，這個open-closed關係需要明確的文檔化，不要隨意打破，否則就會一團糟。

Event-Driven Architecture

The event-driven architecture pattern is a popular distributed asynchronous architecture pattern used to produce highly scalable applications.

從上述定義可以看出事件驅動架構的幾個特點：分佈式、異步、可伸縮。其核心是：高度解耦合、專一職責的事件處理單元(Event Processor)

事件驅動架構有兩種常見拓撲結構： the mediator and the broker.

Mediator Topology

需要一个中心化（全局唯一）的協調單元，用於組織一個事件中的多個步驟，這些步驟中有些是可并行的，有些必須是順序執行的，這就依賴Event Mediator的調度。如下圖所示

Broker Topology
這種是沒有中心的架構

the message flow is distributed across the event processor components in a chain-like fashion through a lightweight message broker

如下圖所示

事件驅動的好處在於，高度可伸縮、便於部署、整體性能較好（得益於某些事件的併發執行）。但由於其分佈式異步的本性，其缺點也很明顯：開發比較複雜、維護成本較高；而且很難支持事務，尤其是一個邏輯事件跨越多個processor的時候。

Microkernel Architecture

微內核架構又稱之為插件式架構（plug-in architecture）。如下圖所示：

微內核架構包含兩部分組件

• a core system
• plug-in modules.

plug-in modules 是相互獨立的組件，用於增加、擴展 core system 的功能。

這種架構非常適用於 product-based applications 即需要打包、下載、安裝的應用，比如桌面應用。最經典的例子就是Eclipse編輯器，玩遊戲的同學經常下載使用的MOD也可以看出插件。

微內核架構通常可以是其他架構的一部分，以實現特定部分的漸進式設計、增量開發

Microservices Architecture Pattern

微服務架構並不是為了解決新問題而發明的新架構，而是從分層架構的單體式應用和SOA（service-oriented architecture）演化而來。

微服務解決了分層架構潛在的成為單體式應用（Monolithic application）的問題：

through the development of continuous delivery, separating the application into multiple deployable units

同時，微服務還通過簡化（泛化）服務的概念，消除編排需求，簡化對服務組件的連接訪問。從而避免了SOA的各種缺點：複雜、昂貴、重度、難以理解和開發。

The microservices architecture style addresses this complexity by simplifying the notion of a service, eliminating orchestration needs, and simplifying connectivity and access to service components.

微服務架構如下：

其核心是service component，這些服務組件相互解耦，易於獨立開發、部署。服務組件的粒度是微服務架構中最難的挑戰

• 太大：失去了微服務架構的優勢
• 太小：導致需要編排，或者服務組件間的通信、事務。

而微服務架構相比SOA而言，其優勢就在於避免依賴和編排 — 編排引入大量的複雜工作。

對於單個請求 如果service之間還要通信，那麼可能是就是粒度過小。解決辦法：

• 如果通信是為了訪問數據：那麼可以通過共享db解決
• 如果通信是為了使用功能：那麼可以考慮代碼的冗餘，雖然這違背了DRY原則。在clean architecture中也指出，component的自完備性有時候要高於代碼復用。

Space-Based Architecture

基於空間的架構，其核心目標是解決由於數據庫瓶頸導致的低伸縮性、低併發問題。

分層架構中，在用戶規模激增的情況下，數據層的擴展往往會成為最後的瓶頸（相對而言，前端和業務邏輯都容易做成無狀態，比較好水平擴展）。而基於空間的架構的核心是內存複製，根本上解決了這個問題。

High scalability is achieved by removing the central database constraint and using replicated in-memory data grids instead

架構如下：

其核心組件包括

• processing unit，處理單元，其內部又包含一下組成
  • business logic
  • in-memory data grid
  • an optional asynchronous persistent store for failover
  • replication engine，用於同步數據修改
• virtualized middleware
  • Messaging Grid: 監控processing unit可用性，路由客戶端請求到processing unit
  • Data Grid: 核心，負責processingunit之間的數據同步，毫秒級同步？
  • Processing Grid: 可選組件，如果一個請求需要多個processing unit的服務，那麼負責協調分發
  • Deployment Manager： 負責processing unit的按需啟停

基於空間的架構很少見，而且從上面的核心組件描述來看的話，開發和維護應該都是比較負責的，由於是數據的同步這塊。而且由於數據都保存在內存中，那麼數據量就不能太大。

基於空間的架構適用於需求變化大的小型web應用，不適用於有大量數據操作的傳統大規模關係型數據庫應用

references

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

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

1.最小生成樹介紹

什麼是最小生成樹？

最小生成樹（Minimum spanning tree，MST）是在一個給定的無向圖G(V,E)中求一棵樹T，使得這棵樹擁有圖G中的所有頂點，且所有邊都是來自圖G中的邊，並且滿足整棵樹的邊權值和最小。

2.prim算法

和Dijkstra算法很像！！請看如下Gif圖，prim算法的核心思想是對圖G(V,E)設置集合S，存放已被訪問的頂點，然後每次從集合V-S中選擇與集合S的最短距離最小的一個頂點（記為u），訪問並加入集合S。之後，令頂點u為中間點，優化所有從u能到達的頂點v與集合s之間的最短距離。這樣的操作執行n次，直到集合s中包含所有頂點。

不同的是，Dijkstra算法中的dist是從源點s到頂點w的最短路徑；而prim算法中的dist是從集合S到頂點w的最短路徑，以下是他們的偽碼描述對比，關於Dijkstra算法的詳細描述請

算法實現：

#include<iostream>
#include<vector>
#define INF 100000
#define MaxVertex 105
typedef int Vertex; 
int G[MaxVertex][MaxVertex];
int parent[MaxVertex];   // 並查集 
int dist[MaxVertex]; // 距離 
int Nv;    // 結點 
int Ne;    // 邊 
int sum;  // 權重和 
using namespace std; 
vector<Vertex> MST;  // 最小生成樹 

// 初始化圖信息 
void build(){
    Vertex v1,v2;
    int w;
    cin>>Nv>>Ne;
    for(int i=1;i<=Nv;i++){
        for(int j=1;j<=Nv;j++)
            G[i][j] = 0;  // 初始化圖 
        dist[i] = INF;   // 初始化距離
        parent[i] = -1;  // 初始化並查集 
    }
    // 初始化點
    for(int i=0;i<Ne;i++){
        cin>>v1>>v2>>w;
        G[v1][v2] = w;
        G[v2][v1] = w;
    }
}

// Prim算法前的初始化 
void IniPrim(Vertex s){
    dist[s] = 0;
    MST.push_back(s);
    for(Vertex i =1;i<=Nv;i++)
        if(G[s][i]){
            dist[i] = G[s][i];
            parent[i] = s;
        } 
}

// 查找未收錄中dist最小的點 
Vertex FindMin(){
    int min = INF;
    Vertex xb = -1;
    for(Vertex i=1;i<=Nv;i++)
        if(dist[i] && dist[i] < min){ 
            min = dist[i];
            xb = i;
        }
    return xb;
}

void output(){
    cout<<"被收錄順序："<<endl; 
    for(Vertex i=1;i<=Nv;i++)
        cout<<MST[i]<<" ";
    cout<<"權重和為："<<sum<<endl; 
    cout<<"該生成樹為："<<endl; 
    for(Vertex i=1;i<=Nv;i++)
        cout<<parent[i]<<" ";
}

void Prim(Vertex s){
    IniPrim(s);
    while(1){
        Vertex v = FindMin();
        if(v == -1)
            break;
        sum += dist[v];
        dist[v] = 0;
        MST.push_back(v);
        for(Vertex w=1;w<=Nv;w++)
            if(G[v][w] && dist[w])
                if(G[v][w] < dist[w]){
                    dist[w] = G[v][w];
                    parent[w] = v;
                }
    }
}


int main(){
    build();
    Prim(1);
    output();
    return 0;
} 

關於prim算法的更加詳細講解請

3.kruskal算法

Kruskal算法也可以用來解決最小生成樹的問題，其算法思想很容易理解，典型的邊貪心，其算法思想為：

• 在初始狀態時隱去圖中所有的邊，這樣圖中每個頂點都是一個單獨的連通塊，一共有n個連通塊
• 對所有邊按邊權從小到大進行排序
• 按邊權從小到大測試所有邊，如果當前測試邊所連接的兩個頂點不在同一個連通塊中，則把這條測試邊加入當前最小生成樹中，否則，將邊捨棄。
• 重複執行上一步驟，直到最小生成樹中的邊數等於總頂點數減一 或者測試完所有邊時結束；如果結束時，最小生成樹的邊數小於總頂點數減一，說明該圖不連通。

請看下面的Gif圖！

算法實現：

#include<iostream>
#include<string>
#include<vector>
#include<queue>
#define INF 100000
#define MaxVertex 105
typedef int Vertex; 
int G[MaxVertex][MaxVertex];
int parent[MaxVertex];   // 並查集最小生成樹 
int Nv;    // 結點 
int Ne;    // 邊 
int sum;  // 權重和 
using namespace std; 
struct Node{
    Vertex v1;
    Vertex v2;
    int weight; // 權重 
    // 重載運算符成最大堆 
    bool operator < (const Node &a) const
    {
        return weight>a.weight;
    }
};
vector<Node> MST;  // 最小生成樹 
priority_queue<Node> q;   // 最小堆 

// 初始化圖信息 
void build(){
    Vertex v1,v2;
    int w;
    cin>>Nv>>Ne;
    for(int i=1;i<=Nv;i++){
        for(int j=1;j<=Nv;j++)
            G[i][j] = 0;  // 初始化圖
        parent[i] = -1;
    }
    // 初始化點
    for(int i=0;i<Ne;i++){
        cin>>v1>>v2>>w;
        struct Node tmpE;
        tmpE.v1 = v1;
        tmpE.v2 = v2;
        tmpE.weight = w;
        q.push(tmpE); 
    }
}

//  路徑壓縮查找 
int Find(int x){
    if(parent[x] < 0)
        return x;
    else
        return parent[x] = Find(parent[x]);
} 

//  按秩歸併 
void Union(int x1,int x2){
    if(parent[x1] < parent[x2]){
        parent[x1] += parent[x2];
        parent[x2] = x1;
    }else{
        parent[x2] += parent[x1];
        parent[x1] = x2;
    }
} 

void Kruskal(){
    // 最小生成樹的邊不到 Nv-1 條且還有邊 
    while(MST.size()!= Nv-1 && !q.empty()){
        Node E = q.top();  // 從最小堆取出一條權重最小的邊
        q.pop(); // 出隊這條邊 
        if(Find(E.v1) != Find(E.v2)){  // 檢測兩條邊是否在同一集合 
            sum += E.weight; 
            Union(E.v1,E.v2);     // 並起來 
            MST.push_back(E);
        }
    }
    
} 


void output(){
    cout<<"被收錄順序："<<endl; 
    for(Vertex i=0;i<Nv;i++)
        cout<<MST[i].weight<<" ";
    cout<<"權重和為："<<sum<<endl; 
    for(Vertex i=1;i<=Nv;i++)
        cout<<parent[i]<<" ";
    cout<<endl;
}


int main(){
    build();
    Kruskal();
    output();
    return 0;
} 

關於kruskal算法更詳細的講解

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

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

主機配置：DHCP

　　DHCP（動態主機配置協議），是在一台主機啟動后，第一個運行的客戶/服務器應用程序。換言之，當一台主機啟動后，如果它認為自己當前應當連接到因特網上，但又不知道自己的IP地址時，DHCP就以引導程序的身份發揮作用。

　　每個連接到TCP/IP互聯網的計算機都必須知道自己的IP地址、一個路由器的IP地址、一個名字服務器的IP地址以及自己的子網掩碼這四種信息。

 DHCP分組格式：

一、曾經使用過的協議

　　在DHCP成為正式的主機配置協議之前，還有過一些其他的協議。

1.RARP：

　　在因特網時代的初期，人們曾設計了一個稱為逆地址解析協議（Reverse Address Resolution Protocol，RARP）來向被引導的主機提供IP地址。實際上，RARP是ARP的一個版本。ARP將一個IP地址映射為一個物理地址，而RARP則將一個物理地址映射成為一個IP地址。但是RARP已經被淘汰了，原因有兩個：首先，RARP利用了數據鏈路層的廣播服務，這也就表示每個網絡上都必須存在一台RARP服務器。第二，RARP只能提供計算機的IP地址，但如今的計算機需要前面提到的所有四種信息。

2.BOOTP：

　　引導程序協議（BOOTstrap Protocol，BOOTP）是DHCP的先驅。它是一個客戶/服務器協議，被設計用來克服RARP協議存在的缺陷。但是BOOTP是一個靜態配置協議，當客戶請求自己的IP地址時，BOOTP服務器就諮詢一張表，將客戶的物理地址映射成相應的IP地址。這就意味着客戶的物理地址和IP地址之間的綁定是已經存在的。這個綁定關係是事先設定好的。

　　在某些場合，我們需要的是一個動態配置協議。例如，當一台主機從一個物理網絡移動到另一個物理網絡時，它的物理地址就改變了。再比如，有時候主機需要在某一段時間內使用一個臨時的IP地址。BOOTP無法處理這種狀況，因為物理地址和IP地址之間的綁定是靜態的，是固定存放在一張表中的，除非管理員更改這張表。

　　而DHCP的設計就是為了解決這些不足之處。

3. DHCP：

　　動態主機配置協議（Dynamic Host Configuration Protocol，DHCP）是一種客戶/服務器協議，設計這個協議是為了將上述四種信息傳遞給無盤計算機或者第一次啟動的計算機。DHCP是BOOTP的繼承者，並且能夠兼容BOOTP。 

二、DHCP操作

　　DHCP客戶和DHCP服務器可以在同一個網絡上，也可以位於不同的網絡。

1.DHCP客戶和DHCP服務器在同一個網絡

　　雖然這種情況不是很常見，不過管理員可以把客戶和服務器放在同一個網絡中。如圖所示：

這種情況的操作如下：

（1）DHCP服務器在UDP端口67發出被動打開命令，等待客戶請求。

（2）被引導的客戶在UDP端口68發出主動打開命令。這個報文被封裝成UDP用戶報，其目的端口是67，源端口號是68。這個UDP用戶數據報在封裝成IP數據包。客戶使用的是全0的源地址和全1的目的地址。

（3）服務器或者用廣播報文，或者用單播報文來響應這個用戶，它使用了UDP源端口號67和目的端口68.這個響應可以是單播的，因為服務器知道客戶的IP地址，同時也知道客戶的物理地址，也就是說它不需要使用ARP的服務進行從邏輯地址到物理地址的映射。但是某些系統不允許旁路掉ARP，結果就要使用廣播地址。

2. DHCP客戶和DHCP服務器在不同的網絡

如圖所示：

 
　　像其他應用層的進程一樣，客戶可以在某個網絡上，而服務器可以在相隔好幾個網絡之外的另一網絡上。這就帶來了一個必須要解決的問題。DHCP請求是廣播發送的，因為客戶不知道服務器的IP地址。而廣播的IP數據報不能通過任何路由器。路由器收到這樣的分組就丟棄它。

　　要解決這個問題，就需要一个中介物。某台主機（或是一台能夠配置為在應用層工作的路由器）可以用來充當中繼。在這種情況下，該主機就稱為中繼代理。中繼代理知道DHCP服務器的單播地址，並在端口67監聽廣播報文。當它收到這種類型的分組后，就把它封裝成一個單播數據報，並且把此請求發送給DHCP服務器。攜帶了單播目的地址的分組可以被任何一個路由器轉發，最終到達DHCP服務器。DHCP服務器知道這個報文來自中繼代理，因為在請求報文中有一個字段定義了中繼代理的IP地址。中繼代理在收到回答后，再把它發送給DHCP客戶。 

三、配置

　　人們設計DHCP是為了提供靜態和動態的地址分配。

1.靜態地址分配

　　對於靜態地址分配，DHCP有一個專門的數據庫，可以靜態地吧物理地址綁定到IP地址。

2.動態地址分配

　　DHCP還有第二個數據庫，包括一個可用的IP地址池。第二個數據庫使DHCP成為動態的。當DHCP客戶請求臨時的IP地址時，DHCP服務器就從可用（即為使用的）IP地址池中取出一個IP地址進行指派，這個IP地址的使用時間長短可協商。

　　當DHCP客戶想DHCP服務器發送請求是，服務器首先檢查它的靜態數據庫。若靜態數據庫中存在所請求物理地址的表項，則返回給這個客戶的永久IP地址。反之，若靜態數據庫中沒有這個表項，服務器就從可用IP地址池中選擇一個IP地址，並把這個地址指派給客戶，然後再把相應的表項加入到動態數據庫中。

　　如果主機要從一個網絡移動到另一個網絡，或者與一個網絡時連時斷，那麼DHCP的這種動態特性就有了用武之地。DHCP可以在有限時間內提供一個臨時的IP地址。

從地址池指派的地址都是臨時地址。DHCP服務器向客戶授予某一段時間內對該地址池的租用權。當租用時效過期，客戶或者停止使用這個IP地址，或者續租。服務器有權力選擇同意或不同意續租。若服務器不同意，客戶就停止使用這個地址。

3.轉換狀態

　　為了提供動態的地址分配，DHCP客戶可以像狀態機那樣從一個狀態轉換到另一個狀態，狀態轉換取決於收到的報文和發送的報文。在這種情況下，報文的類型是由包含在DHCP分組中的標記為53的選項來定義的。標記為53 的選項如圖所示：

DHCP的不同狀態：

（1）INIT狀態

　　當DHCP客戶首次啟動時，它處於INIT狀態（初始化狀態）。客戶使用端口67廣播DHCPDISCOVER報文（一個帶有DHCPDISCOVER選項的請求報文）。

（2）SELECTING狀態

　　在發送DHCPDISCOVER報文後，客戶就進入SELECTING（選擇）狀態。能夠提供這種類型服務的服務器要用DHCPOFFER報文進行相應。在此類報文中，服務器提供了一個IP地址。它們還要提供租用時間長度，其默認值是1小時。在發送DHCPOFFER報文的服務器，把提供的IP地址鎖定，使這個地址不會再提供給任何其他的客戶。客戶選擇所提供的地址中的一個，並向所選擇的服務器發送DHCPREQUEST報文。然後就進入REQUESTING狀態。如果客戶沒有收到DHCPOFFER報文，它還要再嘗試四次，每一次間隔2秒。如果對這些DHCPDISCOVER都沒有收到回答，客戶就睡眠5分鐘后再試。

（3）REQUESTING狀態

　　客戶保持在這個REQUESTING（請求）狀態，直至它收到來自服務器的DHCPACK報文為止，這個報文創建了客戶物理地址和它的IP地址之間的綁定。客戶收到DHCPACK報文後進入BOUND狀態。

（4）BOUND狀態

　　在這種狀態下，客戶可以使用該IP地址，直到租用時間到期。當到達租用時間的50%時，客戶就再發送一個DHCPREQUEST報文以請求更新。於是，客戶進入RENEWING。在BOUND（綁定）狀態時，客戶也可以取消租用，並進入到初始化狀態。

（5）RENEWING狀態

　　客戶保持在RENEWING（更新）狀態，直至下面兩個事件之一發生。客戶可以收到更新租用協定的DHCPACK報文。在這種情況下，客戶把計時器複位，然後回到BOUND狀態。或者，如果沒有收到DHCPACK，同時到達租用時間的87.5%時，客戶就進入REBINDING狀態。

（6）REBINDING狀態

　　客戶保持在REBINDING（重新綁定）狀態，直至下面三個事件之一發生。若客戶收到一個DHCPNACK報文或者租用時間到期，則回到初始化狀態，並嘗試得到另一個IP地址。若客戶收到DHCPACK報文，它就進入綁定狀態，並把計時器複位。

DHCP不同狀態的轉換圖：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

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