EV弱點一次解決!豐田傳推全固體電池車、數分鐘充飽電

東京新聞25日報導,豐田汽車(Toyota)計畫在2022年於日本國內開賣新型電動車(EV),其電池將採用充電量可達鋰離子電池2倍的「全固體電池」,將大幅提升EV的續航距離,且僅需數分鐘時間就可充飽電。在EV的研發上,由歐美廠商跑在前頭,而豐田期望藉由導入革新性技術扳回劣勢。

報導指出,現行市售的EV所搭載的電池以鋰離子電池為主,不過其弱點在於充飽一次電所能行駛的距離約300-400km、遜於汽油車,且即便使用快速充電技術、也需花費數十分鐘才能充飽電,而採用全固體電池的話,就有望一口氣將上述弱點全數解決。

據報導,全固體電池是將電解質從液體變更為固體,而豐田長年來持續進行全固體電池的研發,並於去年宣佈已攜手東京工業大學成功發現可適用於電解質的固體材料,並將在今年開始進行量產研發。

德國BMW、福斯(Volkswagen)等車廠也正研發全固體電池,不過量產相關計畫仍未明。

日經新聞曾於2011年10月報導,豐田汽車已和東京工業大學及高能源加速器研究機構攜手研發出一款使用新化合物的次世代電動車(EV)用「全固體電池」,其充飽一次電所能行駛的距離最長有望達1,000km左右的水準。

富士經濟6月22日公布調查報告指出,預估2030年時EV年銷售量將增至407萬台、超越油電混合車(HV、2030年銷售量預估為391萬台),且之後雙方的差距將持續擴大。富士經濟預估,在中國需求增加加持下,2035年EV全球銷售量將擴大至630萬台、將達2016年的13.4倍(較2016年增加12.4倍)。

(本文內容由授權使用。圖片出處:Toyota)

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

【其他文章推薦】

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

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

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

java中的string對象深入了解

這裏來對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 layeropen 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網頁設計已成為網頁設計推薦首選

PL真有意思(三):名字、作用域和約束

前言

這兩篇寫了詞法分析和語法分析,比較偏向實踐。這一篇來看一下語言設計里一個比較重要的部分:名字。在大部分語言里,名字就是標識符,如果從抽象層面來看名字就是對更低一級的內存之類的概念的一層抽象。但是名字還有其它相關的比如它的約束時間和生存周期等等

約束時間

約束就是兩個東西之間的一種關聯,例如一個名字和它所命名的事物,約束時間就是指創建約束的時間。有關的約束可以在許多不同的時間作出

  • 語言設計時
  • 語言實現時
  • 編寫程序時
  • 編譯時
  • 鏈接時
  • 裝入時
  • 運行時

這就是為什麼基於編譯的語言實現通常會比基於解釋器的語言的實現更高效的原因,因為基於編譯的語言在更早的時候就做了約束,比如對於全局變量在編譯時就已經確定了它在內存中的布局了

對象生存期和存儲管理

在名字和它們所引用的對象的約束之間有幾個關鍵事件

  • 對象的創建
  • 約束的創建
  • 對變量、子程序、類型等的引用,所有這些都使用了約束
  • 對可能暫時無法使用的約束進行失活或者重新約束
  • 約束的撤銷
  • 對象的撤銷

對象的生存期和存儲分配機制有關

  • 靜態對象被賦予一個絕對地址,這個地址在程序的整個執行過程中都保持不變
  • 棧對象按照後進先出的方式分配和釋放,通常與子程序的調用和退出同時進行
  • 堆對象可以在任意時刻分配或者釋放,它們要求更通用的存儲管理算法

靜態分配

全局變量是靜態對象最顯而易見的例子,還有構成程序的機器語言翻譯結果的那些指令,也可以看作是靜態分配對象。

還有像每次調用函數都會保持相同的值的局部變量也是靜態分配的。對於數值和字符串這些常量也是靜態分配。

還有用來支持運行時的各種程序,比如廢料收集和異常處理等等也可以看作是靜態分配

基於棧的分配

如果一種語言允許遞歸,那麼局部變量就不能使用靜態分配的方式了,因為在同一時刻,一個局部變量存在的實例個數是不確定的

所以一般對於子程序,都用棧來保存它相關的變量信息。在運行時,一個子程序的每個實例都在棧中有一個相應的棧幀,保存着它的參數、返回值、局部變量和一些簿記信息

基於堆的分配

堆是一塊存儲區域,其中的子存儲塊可以在任意時間分配與釋放。因為堆具有它的動態性,所以就需要對堆空間進行嚴格的管理。許多存儲管理算法都維護着堆中當前尚未使用的存儲塊的一個鏈接表,稱為自由表。

初始時這個表只有一個塊,就是整個堆,每當遇到分配請求時,算法就在表中查找一個大小適當的塊。所以當請求次數增多,就會出現碎片問題,也需要相應的解決

所以有廢料收集的語言其實就是對堆的管理

作用域作用

一個約束起作用的那一段程序正文區域,稱為這個約束的作用域。

現在大多數語言使用的都是靜態作用域,也就是在編譯時就確定了。也有少數語言使用動態作用域,它們的約束需要等到運行時的執行流才能確定

靜態作用域

在使用靜態作用域的語言,也叫作詞法作用域。一般當前的約束就是程序中包圍着一個給定點的最近的,其中有與該名字匹配的聲明的那個快中建立的那個約束。比如C語言在進入子程序時,如果局部變量和全局變量,那麼當前的約束就是與局部變量關聯,直到退齣子程序才撤銷這個約束

但是有的語言提供了一種可以提供約束的生存期的機制,比如Fortran的save和C的static

嵌套子程序

有許多語言允許一個子程序嵌套在另一個子程序的。這樣有關約束的定義通常來說都是首先用這個名字在當前、最內層的作用域中查找相應的聲明,如果找不到就直接到更外圍的作用域查找當前的約束,直到到達全局作用域,否則就發生一個錯誤

訪問非局部變量

上面提到的訪問外圍作用域的變量,但是當前子程序只能訪問到當前的棧幀,所以就需要一個調用幀鏈來讓當前的作用域訪問到外圍作用,通過調用順序形成一個靜態鏈

聲明的順序

關於約束還有一個問題,就是在同一作用域里,先聲明的名字是否能使用在此之後的聲明

在Pascal里有這樣兩條規則:

  1. 修改變量要求名字在使用之前就進行聲明
  2. 但是當前聲明的作用域是整個程序塊

所以在這兩個的相互作用下,會造成一個讓人吃驚的問題

const N = 10;

procedure foo;
const
  M = N; (*靜態語義錯誤*)
  N = 20;

但是在C、C++和Java等語言就不會出現這個問題,它們都規定標識符的作用域不是整個塊,而是從其聲明到塊結束的那一部分

並且C++和Java還進一步放寬了規則,免除了使用之前必須聲明的要求

模塊

恰當模塊化的代碼可以減少程序員的思維負擔,因為它最大限度的減少了理解系統的任意給定部分時所需的信息量。在設計良好的程序中,模塊之間的接口應盡可能的小,所有可能改變的設計決策都隱藏在某個模塊里。

模塊作為抽象

模塊可以將一組對象(如子程序、變量、類型)封裝起來。使得:

  1. 這些內部的對象相互可見
  2. 但是外部對象和內部對象,除非显示的導入,否則都是不可見的

模塊作為管理器

模塊使我們很容易的創建各種抽象,但是如果需要多個棧的實例,那麼就需要一個讓模塊成為一個類型的管理器。這種管理器組織方式一般都是要求在模塊中增加創建/初始化函數,並給每一個函數增加一個用於描述被操作的實例

模塊類型

對於像這種多實例的問題,除了管理器,在許多語言里的解決方法都是可以將模塊看作是類型。當模塊是類型的時候,就可以將當前的方法認為是屬於這個類型的,簡單來說就是調用方法變化了

push(A, x) -> A.push(x)

本質上的實現區別不大

面向對象

在更面向對象里的方法里,可以把類看作是一種擴充了一種繼承機制的模塊類型。繼承機制鼓勵其中所有操作都被看作是從屬於對象的,並且新的對象可以從現有對象繼承大部分的操作,而不需要為這些操作重寫代碼。

類的概念最早應該是起源於Simula-67,像後來的C++,Java和C#中的類的思想也都起源於它。類也是像Python和Ruby這些腳本語言的核心概念

從模塊到模塊類型再到類都是有其思想基礎,但是最初都是為了更好的數據抽象。但是即使有了類也不能完全取代模塊,所以許多語言都提供了面向對象和模塊的機制

動態作用域

在使用動態作用域的語言中,名字與對象間的約束依賴於運行時的控制流,特別是依賴子程序的調用順序

n : integer

procedure first
  n := 1

procedure second
  n : integer
  first()

n := 2
if read_integer() > 0
  second()
else
  first()
write_integer()

這裏最後的輸出結果完全取決於read_integer讀入的数字的正負,如果為正,輸出就為2,否則就打印一個1

作用域的實現

為了跟蹤靜態作用域程序中的哥哥名字,編譯器需要依靠一個叫做符號表的數據結構。從本質上看,符號表就是一個記錄名字和它已知信息的映射關係的字典,但是由於作用域規則,所以還需要更強大的數據結構。像之前那個寫編譯器系列的符號表就是使用哈希表加上同一層作用域鏈表來實現的

而對於動態作用域來說就需要在運行時執行一些操作

作用域中名字的含義

別名

在基於指針的數據結構使用別名是很自然的情況,但是使用別名可能會導致編譯器難以優化或者造成像懸空引用的問題,所以需要謹慎使用

重載

在大多數語言中都或多或少的提供了重載機制,比如C語言中(+)可以被用在整數類型也可以用在浮點數類型,還有Java中的String類型也支持(+)運算髮

要在編譯器的符號表中處理重載問題,就需要安排查找程序根據當前的上下文環境返回一個有意義的符號

比如C++、Java和C#中的類方法重載都可以根據當前的參數類型和數量來判斷使用哪個符號

內部運算符的重載

C++、C#和Haskell都支持用戶定義的類型重載內部的算術運算符,在C++和C#的內部實現中通常是將A+B看作是operator+(A, B)的語法糖

多態性

對於名字,除了重載還有兩個重要的概念:強制和多態。這三個概念都用於在某些環境中將不同類型的參數傳給一個特定名字的子程序

強制是編譯器為了滿足外圍環境要求,自動將某類型轉換為另一類型的值的操作

所以在C中,定義一個計算整數或者浮點數兩個值中的最小值的函數

double min(double x, double y);

只要浮點數至少有整數那麼多有效二進制位,那麼結果就一定會是正確的。因為編譯器會對int類型強制轉換為double類型

這是強制提供的方法,但是多態性提供的是,它使同一個子程序可以不加轉換的接受多種類型的參數。要使這個概念有意義,那麼這多種類型肯定要具有共同的特性

顯式的參數多態性就叫做泛型,像Ada、C++、Clu、Java和C#都支持泛型機制,像剛才的例子就可以在Ada中用泛型來實現

generic
  type T is private;
  with function "<" (x, y : T) return Boolean;
function min(x, y : T) return T;

function min(x, y : T) return T is
begin
  if x < y then return x;
  else return y;
  end if;
end min

function string_min is new min(string, "<")
function date_min is new min(date, date_precedes);

像List和ML中就可以直接寫

(define min (lambda (a b) (if (< a b) a b)))

其中有關類型的任何細節都由解釋器處理

引用環境的約束

提到引用環境的約束就有兩種方式:淺約束和深約束

推遲到調用時建立約束的方式淺約束。一般動態作用域的語言默認是淺約束,當然動態作用域和深約束也是可以組合到一起的。
執行時依然使用傳遞時的引用環境,而非執行時的引用環境。那麼這種規則稱為深約束,一般靜態作用域的語言默認是深約束

閉包

為了實現神約束,需要創建引用環境的一種顯示錶示形式,並將它與對有關子程序的引用捆綁在一起,這樣的捆綁叫做閉包

總而言之,如果子程序可以被當作參數傳遞,那麼它的引用環境一樣也會被傳遞過去

一級值和非受限生存期

一般而言,在語言中,如果一個值可以賦值給變量、可以當作參數傳遞、可以從子程序返回,那麼它被稱為具有一級狀態(和我們在js中說函數是一等公民一個含義)。大多數的語言中數據對象都是一級狀態。二級狀態是只能當作參數傳遞;三級值則是連參數也不能做,比如C#中一些+-*/等符號。

在一級子程序會出現一個複雜性,就是它的生存期可能持續到這個子程序的作用域的執行期外。為了避免這一問題,大部分函數式語言都表示局部變量具有非受限的生命周期,它們的生命周期無限延長,直到GC能證明這些對象再也不使用了才會撤銷。那麼不撤銷帶來的問題就是這些子程序的存儲分配基於棧幀是不行了,只能是基於堆來分配管理。為了維持能基於棧的分配,有些語言會限制一級子程序的能力,比如C++,C#,都是不允許子程序嵌套,也就從根本上不會存在閉包帶來的懸空引用問題。

小結

這一篇從名字入手,介紹了名字與其背後的對象的約束關係、以及約束時間的概念;然後介紹了對象的分配策咯(靜態、棧、堆);緊接着討論了名字與對象之間建立的約束的生命周期,並由此引出了作用域的概念;進一步延伸出多個約束組成的引用環境的相關概念以及問題。

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

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

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

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

【algo&ds】8.最小生成樹

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網頁設計已成為網頁設計推薦首選

電動車需求高、鋰價漲,澳洲Orocobre擴產

澳洲礦商Orocobre Limited聲稱鋰礦需求強、報價攀高,將擴產碳酸鋰,消息傳來激勵股價在8月31日飆高。

Barron’s.com、The Australian報導,Orocobre公布的全年度財報首度轉虧為盈,淨利來到1,940萬美元、遠優於去年的淨損2,200萬美元,而用於電池等工業產品的碳酸鋰,也將擴充產能。

Orocobre估計,2018會計年度的碳酸鋰產出,將從2017年度的11,862公噸擴充到14,000公噸,而2018年度的碳酸鋰均價,每噸則有望超過1萬美元。該公司在2017年度共計售出12,296公噸的碳酸鋰,每噸均價為9,763美元,4-6月當季的均價則是10,696美元,生產成本為3,710美元。

執行長Richard Seville說,全球鋰礦市場的基本面依舊穩健,不但需求強勁、供給吃緊,報價也相當具有吸引力。為了滿足特定電池夥伴的需求,Orocobre會分階段擴充Olaroz鋰礦廠的產能。

依據Orocobre計畫,位於阿根廷的Olaroz鋰礦廠,產能料將倍增。另外,該公司還會跟豐田通商(Toyota Tsusho Corporation)一同打造一座廠房,預計將年產10,000公噸的氫氧化鋰(lithium hydroxide)。

採用鋰電池的電動車需求日增、電池榮景全無降溫跡象,隨著鋰礦供給愈來愈難尋、未來恐有短缺之虞。

OilPrice.com 8月22日報導,特斯拉(Tesla Inc.)內華達州的Gigafactory超級電池廠,估計一年要生產50萬顆車用電池,另外還有諸多車用鋰電池廠也在加緊趕工,顯示未來鋰礦的需求將只增不減,且大部分將來自中國。全球如今有51%的鋰電池是在中國生產,僅10%產自美國。據統計,大陸業者規劃中的車用電池廠,產能預料會在2021年底前達到120億瓦小時(GW hours),是特斯拉內華達州電池廠的三倍之多。

然而,採集鋰礦在技術上其實有相當難度,成本不但高昂,且由於採礦過程牽涉到蒸餾法,產出也頗難預估。Orocobre在阿根廷北部設立的新礦場,鋰礦產出就比預期少逾20%。

假如鋰礦產能無法順利擴充、或是新開礦場產出不如預期,那麼電動車的榮景可能因而受阻。Electrek報導,福斯汽車(Volkswagen)研發部主管Ulrich Eichhorn 6月底就曾預估,業界需要多達40座規模跟特斯拉Gigafactory類似的超大電池廠,才能滿足電動車需求,假如新建礦場、工廠無法如期上線,那麼市場恐陷入短缺。

(本文內容由授權使用。圖片出處:public domain CC0)

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

【其他文章推薦】

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

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

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

谷歌打擊流氓索權APP:限制第三方移動軟件訪問用戶數據

  騰訊科技訊,手機軟件的“流氓索權”行為遭到了全球輿論的炮轟,媒體譴責流氓軟件大肆採集用戶的隱私信息,侵犯消費者權益。據外媒最新消息,谷歌最近宣布了一項新政策,對於違規採集手機短信和通話記錄的軟件,將做出撤架的懲罰。谷歌也將允許通話有關的軟件,繼續訪問用戶數據。

  據國外媒體報道,為了應對谷歌社交網絡 Google+ 之前爆出的隱私漏洞,該公司宣布了“閘門計劃”,準備限制第三方移動軟件訪問用戶數據,保護消費者隱私權已。

  谷歌規定,在安卓操作系統中,只有特定的客戶端軟件才能夠訪問用戶的短信和通話記錄。據報告,谷歌日前正式對外宣布,該公司將很快開始刪除發現違反規定的 Play 軟件商店中的應用程序。

  在很大程度上,谷歌希望將安卓手機上的短信記錄和通話歷史訪問權限限定於特定的安卓軟件,其中包括短信工具和撥號軟件。谷歌準備限制其他和通信功能無關的應用軟件採集用戶的通信歷史。

  谷歌公司表示:“我們的新政策旨在確保請求這些權限的應用程序對敏感數據進行全面和持續的訪問,以完成應用程序的主要使用功能,並確保用戶理解為什麼應用程序需要這些數據才能運行。”

  自去年 10 月以來,谷歌一直通過电子郵件與安卓應用軟件開發者聯繫,給他們 90 天的時間讓他們的應用程序符合最新規定的要求,或者請求谷歌破例待遇。谷歌規定允許開發人員在 3 月 9 日之前進行軟件更新,調整採集用戶數據的權限。

  該公司日前分享了在法規遵循方面的一些進展,包括最近幾個月如何根據開發人員的反饋擴展批準的應用軟件清單。“數以萬計的開發人員”要麼更新了應用程序以遵循新的政策,要麼請求擴展。谷歌還指出,它自己的應用程序也遵循同樣的標準。據悉,對破例情況進行審查的過程如下:

  ——普通用戶可能會理解為什麼這類應用程序需要完全訪問數據。

  ——該功能的用戶優勢。

  ——與應用程序的核心功能相關的權限的重要性。

  ——使用此用例的所有應用程序都存在訪問此敏感數據的風險。

  ——啟用該功能的備選方案的可用性。

  雖然某些使用功能不再被允許,但谷歌公司指出,該公司審核的許多安卓應用軟件,可以通過一個範圍更窄的軟件開發接口(API)來實現軟件的某些功能,而不是要求獲得訪問用戶隱私的權限。

  谷歌舉例說,使用短信功能進行用戶身份認證的開發人員可以選擇使用 SMS Shareever API,而希望使用短信功能共享內容的應用程序可以預先填充一條消息,並觸發默認的 SMS 應用程序加以显示。

  谷歌也表示,與此同時,未請求功能擴展的安卓應用程序將在“未來幾周內”從谷歌 Play 軟件商店中刪除。

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

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

再擴大充電網路,特斯拉宣布將開始在市區設置充電站

 

除了擴建超級充電站、推出家用充電器安裝選擇,特斯拉(Tesla)近日又宣布將在美國一些大型城市內設置市區充電站,來提供給駕駛人更方便的充電選擇。

根據特斯拉透露,市區內的小型充電站將會先在芝加哥、波士頓推出,市區充電站僅能夠提供約72kW 的電力,大約是以往超級充電站120kW 功率的一半,這意味著充電時間會稍微變長,大約會需要45-50 分鐘來為汽車充電。

但在市區充電站中,電動車將不會受到超級充電站內那種「充電分流」的影響,即使另一輛車使用相鄰的充電器,雙方的充電功率也不會因為分流而降低,讓駕駛在高密度人口的城市內也能夠享受快速、實惠的充電。

 

Major increases in the Supercharger and Tesla urban charger network happening over the next several months

— Elon Musk (@elonmusk)

 

除此之外,為了讓駕駛人在汽車充電時不會無聊,特斯拉計畫將這些充電站設置在超級市場、購物中心和市中心的景點附近,讓駕駛能夠利用時間去採買或逛街。市區充電站的收費也將和超級充電站一致,價格遠比汽油的花費便宜的多。

特斯拉希望透過這些市區充電站的設置,能在家庭充電器或目的地級充電站之外,提供給駕駛一個新的選擇,並慢慢達成特斯拉遠大計劃的一部分——建立一個完整的充電網路,讓特斯拉駕駛能夠開車到達世界各地。

「我們會持續擴大充電網路,讓特斯拉駕駛無論身在何處,都能隨時找到可靠的方法取得電力。」

(合作媒體:。圖片出處:)

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

【其他文章推薦】

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

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

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

特斯拉「電池交換技術」新專利曝光,為將推出的電動連結車鋪路?

 

最近,汽車廠商特斯拉(Tesla)於4 月底新申請的「電池交換系統與技術」專利在外媒報導中爭相曝光,引起不少議論。如果你在趕路中,但汽車電力已經見底,你可以選擇到電池交換站,讓技術人員在15 分鐘內幫你更換好全車電池組,取代前往超級充電站也需等待至少半小時的充電時間。不過這項技術對於充電站點挺充足的美國來說,客戶們似乎不太買單?也許真的有時間壓力的商業卡車會更為青睞。

其實,特斯拉在2013 年就曾現場展示Model S 車款的快速電池互換技術,只要90 秒就能換上充滿電的電池重新上路,執行長Elon Musk 事後謙稱這只是處於測試階段,無法和主流充電市場抗衡,但從特斯拉到了今年還在申請電池交換的新專利就知道,他們顯然一直沒有放棄直接更換電池這條路。

在4 月底提交的這份新專利中,特斯拉描述了一種類似於「汽車升降架」的概念,利用液壓升降機將車子托高之後,由技術人員從車底下「手動」幫車輛進行全車電池組更換,取代了之前的「自動」電池交換設計理念。

(source:)

外媒《Clean Technica》將這項技術描述為「快速交換電能儲存系統(quick-swap Electric Energy Storage System ,縮寫EESS)」,專利明確提到Model X 和Model S 的電池組都可以進行更換,但沒有提及Model 3,外界猜測或許還是可以和系統相容。而目前看來,電池交換系統可以考慮設置在遠途道路上(如兩個城市之間的高速公路),確保車輛一路行駛過來都不會有斷電風險。

不過,由於充電站推行在美國非常成功,更習慣進充電站邊「加油」邊休息聊天的特斯拉客戶們,對於電池更換技術並沒有表現出太熱衷的態度,Elon Musk 之前在提到電池互換策略時也曾表示,如果真的要落實這項技術,最可能推及的是商業車,這讓外界專家紛紛預測它很可能支持特斯拉即將在10 月26 日推出的電動聯結車(semi-truck),不過這一點尚未經官方確認。

(合作媒體:。圖片出處:)  

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

【其他文章推薦】

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

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

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