nodejs入門之模塊

  • nodejs模塊語法與開閉原則
  • nodejs模塊的底層實現

 一、nodejs模塊語法與開閉原則

關於nodejs模塊我在之前的兩篇博客中都有涉及,但都沒有對nodejs模塊的底層做做任何探討,但是為了使相關內容更方便查看比對理解,這裏還是先引入一下之前兩篇博客的連接:

1.1 exports、module.exports、require()實現模塊導出導入:

 1 //示例一:導出原始值數據
 2 //a.js--用於導出數據
 3 let a = 123;
 4 module.exports.a=a;
 5 //inde.js--用於導入a模塊的數據
 6 let aModule = require('./a.js');
 7 console.log(aModule.a); //123
 8 
 9 //示例二:導出引用值數據
10 //a.js--同上
11 function foo(val){ 
12     console.log(val);
13 }
14 module.exports.foo = foo;
15 //index.js--同上
16 let aModule = require('./a.js');
17 let str = "this is 'index' module"
18 aModule.foo(str); //this is 'index' module
19 
20 //示例三:導出混合數據
21 a.js--同上
22 let a = 123;
23 function foo(val){ 
24     console.log(val);
25 }
26 module.exports = {
27     a:a,
28     foo:foo
29 }
30 //inde.js--同上
31 let aModule = require('./a.js');
32 let str = "this is 'index' module"
33 console.log(aModule.a);//123
34 aModule.foo(str); //this is 'index' module

在上面這些示例中,沒有演示exports的導出,暫時可以把它看作與同等於module.exports,例如:

 1 //a.js -- 導出模塊
 2 let a = 123;
 3 function foo(val){ 
 4     console.log(val);
 5 }
 6 exports.a = a;
 7 exports.foo = foo;
 8 
 9 //inde.js -- 引用模塊a
10 let aModule = require('./a.js');
11 let str = "this is 'index' module"
12 console.log(aModule.a);//123
13 aModule.foo(str); //this is 'index' module

但是使用exports導出模塊不能這麼寫:

 1 //a.js
 2 let a = 123;
 3 function foo(val){ 
 4     console.log(val);
 5 }
 6 exports = {
 7     a:a,
 8     foo:foo
 9 }
10 
11 //index.js
12 let aModule = require('./a.js');
13 let str = "this is 'index' module"
14 console.log(aModule);// {} -- 一個空對象

至於為什麼不能這麼寫,暫時不在這裏闡述,下一節關於nodejs模塊底層實現會具體的分析介紹,這裏先來介紹nodejs模塊的一個設計思想。

1.2 nodejs模塊的開閉原則設計實現

1 //a.js -- 導出模塊
2 let num = 123;
3 let str = "this is module 'a'";
4 exports.a = a;
5 
6 //index.js -- 引用模塊a
7 let aModule = require('./a.js');
8 console.log(aModule.num);//123
9 console.log(aModule.str);//undefined

這裏你會發現只有被exports執行了導出的num成員才能被正常導出,而str成員沒有被執行導出,在依賴a.js模塊的index.js中是不能引用到a.js模塊中的str成員。可能你會說這不是很正常嗎?都沒有導出怎麼引用呢?

不錯,這是一個非常正常情況,因為語法就告訴了我們,要想引用一個模塊的成員就必須先在被引用的模塊中導出該成員。然而這裏要討論的當然不會是導出與引用這個問題,而是模塊給我實現了一個非常友好的設計,假設我現在在a.js中有成員str,在index.js模塊中也有成員str,這回衝突嗎?顯然是不會的,即使在a.js中導出str並且在index.js中引用a.js模塊,因為index.js要使用a.js模塊的成員str,需要使用接收模塊變量aModule.str來使用。

 1 //a.js
 2 let num = 123;
 3 let str = "this is module 'a'";
 4 exports.num = num;
 5 exports.str = str;
 6 
 7 //index.js
 8 let aModule = require('./a.js');
 9 let str = "this is module 'index'"
10 console.log(aModule.num);//123
11 console.log(aModule.str);//this is module 'a'
12 console.log(str);//this is module 'index'

基於開閉原則的設計方式,封閉可以讓模塊的內部實現隱藏起來,開放又可以友好的實現模塊之間的相互依賴,這相對於之前我們常用的回調函數解決方案,程序設計變得更清晰,代碼復用變得更靈活,更關鍵的是還解決了js中一個非常棘手的問題——命名衝突問題,上面的示例就是最好的證明。這裏需要拋出一個問題,看示例:

1 //下面這種寫法有什麼問題?
2 //a.js
3 let num = 123;
4 module.exports = num;
5 
6 //index.js
7 let aModule = require('./a.js');
8 let str = "this is module 'index'"
9 console.log(aModule);//123

這種寫法不會報錯,也能正常達到目前的需求,如果從能解決目前的功能需求角度來說,它沒錯。但是開閉原則的重要思想就是讓模塊保持相對封閉,又有更好的拓展性,這樣寫顯然不合適,比如就上面的代碼寫完上線以後,業務又出現了一個新的需求需要a.js模塊導出一個成員str,這時候顯然需要同時更改a.js模塊和index.js模塊,即使新需求不需要index.js來實現也是需要改的。所以維持模塊的開閉原則是良好的編碼風格。

 二、nodejs模塊的底層實現原理

2.1 module.exports與exports的區別:

//a.js
console.log(module.exports == exports);//true

//然後在控制台直接執行a.js模塊
node a.js

實際上它們是沒有區別的,那為什麼在之前的exports不能直接等於一個對象,而module.exports可以呢?這關乎於js的引用值指向問題:

 

 當export被賦值一個對象時,就發生了一下變化:

這時候我們可以確定node不會導出exports,因為前面的示例已經說明了這一點,但是值得我們繼續思考的是,node模塊是依據module.exports、exports、還是它們指向的初始對象呢?這裏你肯定會說是module.exports,因為前面已經有示例是module.exports指向一個新的對象被成功導出,但是我並不覺得前面那些示例能說服我,比如下面這種情況:

 1 //a.js模塊
 2 let num = 123;
 3 function foo(val){
 4     console.log(val);
 5 }
 6 module.exports = {
 7     num:num
 8 }
 9 exports = {
10     foo:foo
11 }
12 //index.js模塊
13 let aModule = require('./a.js');
14 console.log(aModule);//這裡會打印出什麼?

我們現不測試也不猜測,先通過下面的示圖來看下現在的a.js模塊中module.exports、exports、以及它們兩初始指向的空對象的關係圖:

 

 這時候我們來看一下index.js執行會輸出什麼?

{ num: 123 }

所以從這個結果可以看出,最後require()最後導入的是被引用模塊的module.exports。探討到這裏的時候並沒有到達node模塊的終點,我們這裏module.exports、exports、require()是從哪裡來的?node系統內置變量?還是別的?

2.2 node模塊的底層實現原理

這部分的內容其實也沒有太多可以說的,就前面提出來的問題其實有一個方式就可以讓你一目瞭然,只需要在一個js文件中編寫以下代碼,然後使用node執行這個js文件就可以了:

1 console.log(require);      // 一個方法
2 console.log(module);       //  一個對象
3 console.log(exports);      //  一個空對象
4 console.log(__dirname);    //  當前模塊所在路徑
5 console.log(__filename);   //  當前文件的路徑

 這時因為node模塊實際上底層是被放到一個立即執行函數內(不要在乎xyz這個名稱,因為我也不知道node底層到底用的什麼名稱),這些變量其實就是這個函數的參數,這個函數大概是一下形式:

1 function xyz(module.exports,require,module,__filename,__dirname){
2     //...
3     //  這裏就是我們在模塊中寫入的代碼
4     //...
5     return module.exports;
6 }

通過上面的推斷就可以得到下面這樣的結果:

1 console.log(module.exports == arguments[0]);//true
2 console.log(require == arguments[1]);//true
3 console.log(module == arguments[2]);//true
4 console.log(__filename == arguments[3]);//true
5 console.log(__dirname == arguments[4]);//true

通過執行這段打印代碼也確實可以得到這樣的結果,到這裏又有一個值得我們關注的內容,就是每個模塊的module參數:

 1 console.log(module);
 2 Module {
 3     id: '.',//當前模塊的id都是'.',在後面的parent和children裏面的模塊對象上的id就是的對應模塊的filename
 4     exports: {},//這裡是模塊導出對象
 5     parent: null,//這裡是當前模塊被那些模塊引用的模塊對象列表,意思是當前模塊作為那些模塊的父級模塊
 6     filename:'',//這裡是當前文件路徑的絕對路徑
 7     loaded: false,//模塊加載狀態,如果在模塊內部輸出module對象它永遠都會是false,因為只有這個模塊加載完成之後才會被修改成true
 8     children: [
 9         // 這裡是引用模塊module對象列表,意思是當前模塊作為了那些模塊的子模塊
10     ],
11     paths:[ 
12         // 這裡是外部模塊包的路徑列表,從最近的路徑(模塊所在同級路徑)到系統盤路徑所有的node_modules文件夾路徑
13      ] 
14     }

到這裡有可能你還會問為什麼底層實現裏面只有module.exports,沒有export,這個解釋起來真的費勁,下面這一行代碼幫你搞定:

let exports = module.exports;

這篇博客主要介紹了node模塊的內部內容,並未就node模塊基於commonjs規範做任何介紹,是因為在之前的博客中已經有了非常全面的解析,詳細參考博客開始時的連接,關於node模塊加載相關內容也是在那篇博客。

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

【其他文章推薦】

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

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

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

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

吉利擬13.46億元拋售康迪與知豆股份 公告解釋四大原因

7月25日,吉利汽車發佈公告稱,與吉利控股訂立總體出售協議,將以總價人民幣13.46億元轉讓旗下康迪50%、知豆45%兩家合資公司的股份。  
  吉利汽車是第二次發公告出售知豆股份,此前公司已與一名獨立協力廠商投資者簽署框架協定,但由於有關訂約方未能就擬定出售條件達成協議,故該出售事項未落實。出售康迪股份則是首次提及。儘管是左手轉右手,但從公告透露的轉讓原因來看,不排除再從吉利控股轉出康迪、知豆股份的可能性。   一、
專注高端提高品牌形象。康迪和知豆主要生產微型純電動汽車,吉利汽車認為這兩家公司生產的電動 汽車相對低端、售價低廉,且該電動汽車一般速度較低,充電範圍較狹窄,技術較低端。   二、
缺乏控制權和影響力。吉利汽車在公告中提及,康迪和知豆都是合營公司,合營公司的經營策略必須 由吉利汽車和其他投資方共同決定,根據吉利汽車原先掌握的股份,這就意味著吉利汽車對這兩家公司的日常管理並沒有擁有大部分的控制權及大範圍的影響力。   三、
虧損過大。康迪今年一季度淨利虧損約4871萬元,知豆同期虧損約8887萬元。   四、
新能源政策生變。近期中國政府發佈有關補貼資格和免稅的政策會對康迪和知豆旗下的產品組合不利。   文章來源:第一電動網

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

【其他文章推薦】

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

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

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

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

ABB超級電容「閃充」技術,在美獲首筆電動巴士訂單

充電慢、交換電池麻煩,這是全電動車的兩難,尤其是若要發展大眾運輸,全電動公車可不能總是停在路邊充電,為了解決這個問題,機電大廠ABB 推出以超級電容(Supercapacitors)「閃充」技術,如今已經接到第一筆訂單。

2016 年7 月中,美國政府期望推動讓未來的電動車能在10 分鐘內充電完成,不過,其實不用等到未來,ABB 現有的技術就已經讓10 分鐘看起來顯得落伍,因為超級電容可以600kW,在15 秒內閃充,提供電動公車行駛到下一個充電站的電力,而若是需完全充飽電池,也只需要幾分鐘。ABB 已經小規模測試此技術數年。

如今,ABB 接到第一筆商業訂單,來自於公車營運商Tosa,將於日內瓦市郊到機場的公車路線上行駛。這款全電動公車行駛時與一般公車無異,不過總共50 個公車站中,有13 個公車站是充電站,當公車進站時,車頂上會伸出接收器,與車站的充電裝置接觸,在15 秒內閃充,取得可行駛到下一個充電站的電力,而在公車總站,則有200kW充電器,以3~5 分鐘時間將電池完全充飽。

充電站採用超級電容,超級電容的能源密度雖然不如鋰電池,但可緩緩充能,於短時間內一次釋放,除了縮短電動公車的充電時間,使得公車能在靠站時閃充以外,也能減輕電網負擔,因為用電量是平均分攤在緩緩充能的階段,而不是一接上充電座時就突然大增電力需求,充完又需求突降,造成電網調度上的困擾。另一方面,由於分散了負擔,整個充電站可以用較低成本的低電流規劃打造。

這種方式也利於應用太陽能,公車站可設置太陽能發電,為超級電容緩緩充能,充電時間之中萬一有雲飄過,一時中斷供電,也不會產生太大影響。而由於公車班次最多時間是在白天,因此太陽能可發揮相當效用。

ABB 先前將超級電容應用於電車煞車回電,2013 年起,ABB 與Tosa 測試超級電容應用於全電動公車,目前測試結果,其成本已經與柴油車相當,未來隨著相關技術成熟,電池價格進一步下降,將有可能比柴油車更便宜,除了價格以外,全電動公車還有無碳排放、無廢氣空氣污染、噪音低的好處,有助於改善市區生活品質。

這款全電動巴士預定於2018 年全面營運。

來源:

(本文授權轉載自《》──〈〉。圖片來源:)

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

【其他文章推薦】

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

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

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

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

車用電池市場變化,傳日產將出售電池事業

日經新聞5日報導,日產汽車(Nissan)將退出車用電池事業,計畫出售和NEC共同設立的合資子公司「Automotive Energy Supply(以下簡稱AES)」,且除了日本電池廠之外、日產已和多家中國廠商展開出售協商;另外,除了AES之外,日產也計畫出售在美國及英國單獨營運的電池生產事業,且據悉多家中國廠商已表達有意收購的意願。預估日產在評估出售額、員工雇用等條件之後,會在今年內敲定出售對象。

報導指出,AES為日產、NEC分別出資51%、49%於2007年設立的公司,主要生產日產電動車Leaf或油電混合車(HV)所需的鋰離子電池,於車用鋰離子電池市場的市佔率僅次於Panasonic位居第2位,2015年度營收為366億日圓,不過因日產研判比起自家生產、向外部電池廠商採購電池較能進一步調降車輛價格,故決定出售ASE持股。

每日新聞5日報導,日產汽車計畫出售ASE持股,且已和Panasonic以及南韓LG化學(LG Chem)等海外廠商展開協商,而據關係人士透露,出售額預估將達數百億日圓。

日經新聞於6日追加報導指出,隨著日產有意退出車用電池事業,NEC也考慮跟進出售ASE持股,而ASE為全球第2大車用鋰離子電池廠,故日產/NEC出售ASE的舉動恐將對全球車用鋰離子電池的勢力版圖帶來巨大變動。

日經指出,供應鋰離子電池給特斯拉(Tesla)的Panasonic目前正面臨中國廠商的猛烈追趕、導致市佔萎縮,根據調查公司Techno Systems Research指出,2014年Panasonic車用鋰離子電池全球市佔率高達47%,而2015年雖維持首位、但市佔率萎縮至34%;反觀「其他廠商」市佔率從14%飆增至33%,而在「其他廠商」中、比亞迪(BYD)等中國廠商佔了大多數。

另外,LG化學、三星SDI等南韓廠商也在後猛追,且日本村田製作所也收購Sony鋰離子電池事業、今後可能將進軍車用市場,故未來日中韓於車用電池市場的競爭料將更趨激烈。

Sony 7月28日宣布,已和村田製作所締結意向確認書,計畫將電池事業出售給村田,雙方預計在2016年10月中旬簽訂具法律約束力的最終契約,且在獲得相關當局同意之後,目標在2017年3月底完成出售手續。

(本文內容由授權提供)

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

【其他文章推薦】

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

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

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

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

022.掌握Pod-Pod升級和回滾

一 deploymentPod升級和回滾

1.1 deployment升級


若Pod是通過Deployment創建的,可以在運行時修改Deployment的Pod定義(spec.template)或鏡像名稱,並應用到Deployment對象上,系統即可完成Deployment的自動更新操作。 如果在更新過程中發生了錯誤, 則還可以通過回滾操作恢復Pod的版本。

示例:

  1 [root@uk8s-m-01 study]# vi nginx-deployment.yaml
  2 apiVersion: apps/v1beta1
  3 kind: Deployment
  4 metadata:
  5   name: nginx-deployment
  6 spec:
  7   replicas: 3
  8   template:
  9     metadata:
 10       labels:
 11         app: nginx
 12     spec:
 13       containers:
 14       - name: nginx
 15         image: nginx:1.7.9
 16         ports:
 17         - containerPort: 80
 18 
 19 [root@uk8s-m-01 study]# kubectl create -f nginx-deployment.yaml
 20 [root@uk8s-m-01 study]# kubectl get pods



  1 [root@uk8s-m-01 study]# kubectl get deployment			#查看deployment
  2 [root@uk8s-m-01 study]# kubectl set image deployment/nginx-deployment nginx=nginx:1.8.1	#命令更新
  3 [root@uk8s-m-01 study]# kubectl get pods			        #查看升級后的pod



  1 [root@uk8s-m-01 study]# kubectl edit deployment/nginx-deployment			#直接編輯deployment


  1 [root@uk8s-m-01 study]# kubectl rollout status deployment/nginx-deployment		#查看升級情況


  1 [root@uk8s-m-01 study]# kubectl get pods
  2 [root@uk8s-m-01 study]# kubectl describe pod nginx-deployment-7448597cd5-8sng2 | grep Image



1.2 deployment升級原理

  1 [root@uk8s-m-01 study]# kubectl describe deployments/nginx-deployment		#觀察Deployment的更新過程




初始創建Deployment時,系統創建了一個ReplicaSet(nginx-deployment-5754944d6c),並按用戶的需求創建了3個Pod副本。

當更新Deployment時,系統創建了一個新的ReplicaSet(nginx-deployment-b5f766d54),並將其副本數量擴展到1,然後將舊ReplicaSet縮減為2。

之後,系統繼續按照相同的更新策略對新舊兩個ReplicaSet進行逐個調整。

最後,新的ReplicaSet運行了3個新版本Pod副本,舊的ReplicaSet副本數量則縮減為0。


  1 [root@uk8s-m-01 study]# kubectl get rs			#查看多次升級的結果



注意:在整個升級的過程中,系統會保證至少有兩個Pod可用,並且最多同時運行4個Pod,這是Deployment通過複雜的算法完成的。Deployment需要確保在整個更新過程中只有一定數量的Pod可能處於不可用狀態。在默認情況下,Deployment確保可用的Pod總數至少為所需的副本數量(DESIRED)減1,也就是最多1個不可用(maxUnavailable=1)。

1.3 deployment升級策略


在Deployment的定義中,可以通過spec.strategy指定Pod更新的策略,目前支持兩種策略:Recreate(重建)和RollingUpdate(滾動更新),默認值為RollingUpdate。

  • Recreate:設置spec.strategy.type=Recreate,表示Deployment在更新Pod時,會先殺掉所有正在運行的Pod,然後創建新的Pod。
  • RollingUpdate:設置spec.strategy.type=RollingUpdate,表示Deployment會以滾動更新的方式來逐個更新Pod。同時,可以通過設置spec.strategy.rollingUpdate下的兩個參數(maxUnavailable和maxSurge)來控制滾動更新的過程。


    • spec.strategy.rollingUpdate.maxUnavailable:用於指定Deployment在更新過程中不可用狀態的Pod數量的上限。 該maxUnavailable的數值可以是絕對值(例如5)或Pod期望的副本數的百分比(例如10%),如果被設置為百分比,那麼系統會先以向下取整的方式計算出絕對值(整數)。而當另一個參數maxSurge被設置為0時,maxUnavailable則必須被設置為絕對數值大於0。舉例來說,當maxUnavailable被設置為30%時,舊的ReplicaSet可以在滾動更新開始時立即將副本數縮小到所需副本總數的70%。一旦新的Pod創建並準備好,舊的ReplicaSet會進一步縮容,新的ReplicaSet又繼續擴容。整個過程中系統在任意時刻都可以確保可用狀態的Pod總數至少佔Pod期望副本總數的70%。
    • spec.strategy.rollingUpdate.maxSurge:用於指定在Deployment更新Pod的過程中Pod總數超過Pod期望副本數部分的最大值。該maxSurge的數值可以是絕對值(例如5)或Pod期望副本數的百分比(例

  • 如10%)。如果設置為百分比,那麼系統會先按照向上取整的方式計算出絕對數值(整數)。舉例來說,當maxSurge的值被設置為30%時,新的ReplicaSet可以在滾動更新開始時立即進行副本數擴容,只需要保證新舊ReplicaSet的Pod副本數之和不超過期望副本數的130%即可。一旦舊的Pod被殺掉,新的ReplicaSet就會進一步擴容。在整個過程中系統在任意時刻都能確保新舊ReplicaSet的Pod副本總數之和不超過所需副本數的130%。

1.4 deployment回滾


默認情況下,所有Deployment的發布歷史記錄都被保留在系統中,以便於我們隨時進行回滾(可以配置歷史記錄數量)。

  1 [root@uk8s-m-01 study]# kubectl rollout history deployment/nginx-deployment	#查看部署歷史
  2 [root@uk8s-m-01 study]# kubectl rollout history deployment/nginx-deployment  --revision=3	#查看對應的部署歷史版本
  3 [root@uk8s-m-01 study]# kubectl rollout history deployment/nginx-deployment  --revision=2	#查看對應的部署歷史版本




提示:Deployment的更新操作是在Deployment進行部署(Rollout)時被觸發的,即當且僅當Deployment的Pod模板(即spec.template)被更改時才會創建新的修訂版本,例如更新模板標籤或容器鏡像。其他更新操作(如擴展副本數)將不會觸發Deployment的更新操作,因此將Deployment回滾到之前的版本時,只有Deployment的Pod模板部分會被修改。

  1 [root@uk8s-m-01 study]# kubectl rollout undo deployment/nginx-deployment --to-revision=2	#回滾版本
  2 [root@uk8s-m-01 study]# kubectl describe deployment/nginx-deployment


1.5 暫停和恢復deployment


對於一次複雜的Deployment配置修改,為了避免頻繁觸發Deployment的更新操作,可以先暫停Deployment的更新操作,然後進行

配置修改,再恢復Deployment,一次性觸發完整的更新操作,從而避免不必要的Deployment更新操作了。

  1 [root@uk8s-m-01 study]# kubectl get deployments				#查看deployment
  2 [root@uk8s-m-01 study]# kubectl get rs					#查看rs
  3 [root@uk8s-m-01 study]# kubectl rollout pause deployment/nginx-deployment	#暫停deployment
  4 [root@uk8s-m-01 study]# kubectl set image deployment/nginx-deployment nginx=nginx:1.10.3	#升級操作,但由於暫停deployment,因此不會觸發更新
  5 [root@uk8s-m-01 study]# kubectl rollout history deployment/nginx-deployment	#查看歷史版本
  6 [root@uk8s-m-01 study]# kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
  7 [root@uk8s-m-01 study]# kubectl rollout resume deployment/nginx-deployment	#恢復deployment
  8 [root@uk8s-m-01 study]# kubectl get rs
  9 NAME                          DESIRED   CURRENT   READY   AGE
 10 nginx-deployment-7448597cd5   0         0         0       52m
 11 nginx-deployment-84bc94dcb7   1         1         0       6s
 12 nginx-deployment-b5f766d54    3         3         3       55m




  1 [root@uk8s-m-01 study]# kubectl describe deployment/nginx-deployment
  2 [root@uk8s-m-01 study]# kubectl describe pods nginx-deployment-84bc94dcb7-hqxkk | grep Image
  3     Image:          nginx:1.10.3


二 RC升級和回滾

2.1 RC滾動升級


, Kubernetes提供了kubectl rolling-update命令進行對於RC的滾動升級。該命令創建了一個新的RC,然後自動控制舊的RC中的Pod副本數量逐漸減少到0,同時新的RC中的Pod副本數量從0逐步增加到目標值,來完成Pod的升級。

注意:該方式要求新的RC與舊的RC都在相同的命名空間內。

示例:

  1 [root@uk8s-m-01 study]# vi redis-master-controller-v1.yaml
  2 apiVersion: v1
  3 kind: ReplicationController
  4 metadata:
  5   name: redis-master-v1
  6   labels:
  7     name: redis-master
  8 spec:
  9   replicas: 1
 10   selector:
 11     name: redis-master
 12   template:
 13     metadata:
 14       labels:
 15         name: redis-master
 16     spec:
 17       containers:
 18       - name: master
 19         image: kubeguide/redis-master:1.0
 20         ports:
 21         - containerPort: 6379
 22 
 23 [root@uk8s-m-01 study]# kubectl create -f redis-master-controller-v1.yaml


  1 [root@uk8s-m-01 study]# vi redis-master-controller-v2.yaml		#RC升級配置文件
  2 apiVersion: v1
  3 kind: ReplicationController
  4 metadata:
  5   name: redis-master-v2
  6   labels:
  7     name: redis-master
  8     version: v2
  9 spec:
 10   replicas: 1
 11   selector:
 12     name: redis-master
 13     version: v2
 14   template:
 15     metadata:
 16       labels:
 17         name: redis-master
 18         version: v2
 19     spec:
 20       containers:
 21       - name: master
 22         image: kubeguide/redis-master:2.0
 23         ports:
 24         - containerPort: 6379



注意:使用此方式升級的時候需要注意以下兩點:

  1. RC的名字(name) 不能與舊RC的名字相同。
  2. 在selector中應至少有一個Label與舊RC的Label不同, 以標識其為新RC。如上所示新增了一個名為version的Label,以與舊RC進行區分。

  1 [root@uk8s-m-01 study]# kubectl rolling-update redis-master-v1 -f redis-master-controller-v2.yaml
  2 [root@uk8s-m-01 study]# kubectl rolling-update redis-master-v1 --image=kubeguide/redis-master:2.0	#也可直接命令中升級



kubectl通過新建一個新版本Pod, 停掉一箇舊版本Pod,如此逐步迭代來完成整個RC的更新。

2.2 RC回滾

  1 [root@uk8s-m-01 study]# kubectl rolling-update redis-master-v1 --rollback


提示:RC的滾動升級不具有Deployment在應用版本升級過程中的歷史記錄、新舊版本數量的精細控制等功能,RC將逐漸被RS和Deployment所取代,建議用戶優先考慮使用Deployment完成Pod的部署和升級操作。

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

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

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

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

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

中國:科技部2017年對新能源汽車部署38個重點研究任務

近日,中國科技部發佈關於對國家重點研發計畫高新領域重點專項2017年度專案申報指南建議徵求意見的通知。新能源汽車專項的總體目標是,繼續深化實施新能源汽車「純電驅動」技術轉型戰略;升級新能源汽車動力系統技術平臺;抓住新能源、新材料、資訊化等科技帶來的新能源汽車新一輪技術變革機遇,超前部署研發下一代技術;到2020年,建立起完善的新能源汽車科技創新體系,支撐大規模產業化發展。  
  新能源汽車試點專項按照動力電池與電池管理系統、電機驅動與電力電子、電動汽車智慧化、燃料電池動力系統、插電/增程式混合動力系統和純電動力系統6個創新鏈,共部署38個重點研究任務,專項實施週期為5年。其中,對於插電式混合動力系統的考核標準已經逐步完善,對新型高性價比乘用車混合動力總成開發與整車集成的考核標準為:整車加速時間0-100km/h≤5s,0-50km/h≤2.5s;綜合工況純電續駛里程≥70km;燃油消耗量較第四階段油耗限值降低比例≥40%;整車實現銷售≥5000台。   純電動汽車未來的百公里加速要在6S以內,專項對純電動力系統的其中一項考核標準是,在工況下,最大爬坡度≥30%,純電續駛里程≥300km,0-100km/h加速時間≤6s,30分鐘最高車速≥120km/h;電制動降低電能消耗率≥25%;整車具備安全穩定的轉向功能,並實現小批量試驗運行。   電動汽車目前的關鍵技術在於動力電池,專項對與新能源汽車的動力電池和電池管理系統的考核標準是:提交高比能鋰離子電池的安全風險識別方法與評測報告;建立電池的安全評測體系,形成相關安全標準;電池單體能量密度≥300Wh/kg,迴圈壽命≥1500次,成本≤0.8元/Wh,安全性達到國標要求,年生產能力≥1億瓦時。   文章來源:EV世紀

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

【其他文章推薦】

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

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

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

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

三菱汽車五年內推出電動休旅車

搶攻電動車市場,三菱汽車(Mitsubishi Motors)宣布預計在2020年推出純電動休旅車,且將是全球戰略性車款。

報導指出,三菱的澳洲執行長Osamu Masuko透露了2020年發表純電動休旅車的計畫,但其他細節並未公開。市場猜測,這款車會類似Nissan Juke或Ford EcoSport,為中小型休旅車款,並搭配全時四輪驅動系統與自動駕駛系統。

而特斯拉的400公里續航力儼然成了新一代電動車產品的續航力標準。三菱的純電動休旅車續航力,具三菱汽車內部消息透露,也會超過400公里,可與特斯拉車款一較高下。

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

【其他文章推薦】

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

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

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

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

BMW iX3 正式登場,又一款台灣買不到的電動車

搭載第五代 eDrive 技術,續航突破 440 公里的 BMW iX3,今日正式登場,並宣布於明年起在中國、北美和歐洲開賣,台灣消費者幾乎肯定買不到,因為這款車將會在中國製造。

德國汽車大廠 BMW,去年介紹了 iX3 的概念車型後,就受到許多車迷期待,今天終於宣布要在 2020 年正式開賣,先來看看這輛車的規格與性能吧。

BMW iX3 搭載 74 kWh 的新版電池組,根據歐盟標準,滿電里程達到 440 公里,馬達能夠輸出 286 馬力,最大扭力為 400 牛頓米。極速達到每小時 200 公里,零到一百加速時間為 6 秒,能源效率部分,官方並未提供準確數據,只表示會低於 20 kW/100 km,由於 BMW i3 的能源效率約為 15 kW/100 km,因此保守估計 iX3 應該能有差不多的表現。

BMW i3 做為集團最初代的電動車,雖然銷售不算太好,但在品牌效應下,仍然有穩定的市場。iX3 的命名則非常有趣,因為它雖然是集團第二款純電車,但他並不是 i3 的後繼車款,而是新一代的 X3,被定義為首款純電動的 SAV(Sport Activity Vehicle)。

iX3 除了純電版本,還會推出同款的燃油版跟油電板,一車三吃。它所搭載的第五代 eDrive 是 BMW 為了下一個世代的電動車所開發的新動力系統,未來將會使用在 i4 跟 i-NEXT 身上。

無論 BMW 願不願意,iX3 的尺寸和價位都無法避免要跟 Tesla 的 SUV 相比,單純比較性能的話,iX3 跟 Model Y 比較接近,但特斯拉在各方面都小贏一些,價格如果沒意外的話,Model Y 應該會比 iX3 便宜不少,但是考慮到內裝和品牌效應,這兩台車應該會讓不少車主苦惱一番(官方售價尚未公布,推測落在 7 萬美元左右)。

不過台灣車主大概不需要苦惱,因為 ,除非法規鬆綁,否則台灣注定是買不到這台車了。台灣的 BMW 車友如果想要入手新款的 電動車,就要等 2021 年的 i4 了。

▲ 第五代 eDrive 動力元件是 BMW 邁入下一個時代的最重要核心技術。(Source:)

BMW 是少數不打算自行研發電池的傳統車廠,目前 i3 使用的是南韓三星的電池組,而 iX3 將會使用寧德時代的電池組。這家車廠將心力投注在他們的 eDrive 動力系統上,根據目前釋出的訊息來看,BMW 的新款馬達並沒有採用目前常見的永磁同步馬達,而是用他們研發的新系統,將馬達、差速器跟系統電子組件全部整合在一起,變成極為精簡的驅動元件,同時提供優秀的動力表現。

「第五代 eDrive 的驅動元件,重量出力比跟前代相較之下提升了 30%,」BMW 官方發言人表示,不僅效率提升,製作過程中也不再需要使用稀土,未來他們將會大量應用這款驅動元件在各種車型上。

此外,寧德時代提供給 BMW 的方形電池組,採用的是新技術 NMC-811 電池,鎳的比例更高,鈷和錳比例下降,除了成本更低,能量密度也更高。

iX3 另一個隱藏的對手是 Tesla Model Y,由於交車時間尚未明朗,許多車主還在觀望,如果 Model Y 在 2020 年第一季順計出貨,那 BMW iX3 可能會跟 i3 一樣,只能固守基本盤,無法吃下更多電動休旅車的市場。

(合作媒體:。首圖來源:)

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

【其他文章推薦】

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

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

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

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

歐洲可充電公路測試中,預計2018年上市

電動車邊最怕路上沒電,但如果能邊跑邊充電,就不怕沒電的問題,這項殺手級應用聽起來很科幻,但現實世界,可充電公路已進入測試階段,離實際應用應該也不遠了。

將無線充電套件嵌入道路表面上,就成了名符其實的充電道路,美國晶片廠高通近期就在法國測試道路上展示這項技術,稱之為電動車行進間充電(dynamic electric vehicle charging,簡稱DEVC)。

據Economictimes報導,DEVC可對高速行駛之汽車,以最高20kW的功率充電,目前同一條跑道上,DEVC能同時對兩輛電動車進行充電。

歐洲非常重視電動車發展,這項計畫是由歐盟執委會(European Commission)主導,共耗費一千萬美元,來自九個歐盟成員國的25個機構共同參與。報導指出,無線充電電動車預計2017、2018年上市,多數主要車廠正準備制訂全球無線充電標準。

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

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

【其他文章推薦】

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

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

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

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

類加載器 – 命名空間

本博客將沿用中展示的自定義類加載器代碼

複雜類加載情況分析

測試代碼一

首先,新建一個類Test14,重寫默認的構造方法,打印加載該類的類加載器

public class Test14 {
    public Test14() {
        System.out.println("Test14 is loaded by:" + this.getClass().getClassLoader());
    }
}

然後,在新建一個類Test15,同樣重寫默認的構造方法,打印加載該類的類加載器,在構造方法中new出Test14的實例

public class Test15 {
    public Test15() {
        System.out.println("Test15 is loaded by:" + this.getClass().getClassLoader());

        new Test14();
    }
}

測試代碼

public class Test16 {
    public static void main(String[] args) throws Exception {
        test01();
    }

    private static void test01 () throws Exception {
        ClassLoaderTest classLoader = new ClassLoaderTest("classLoader");
        Class<?> clazz = classLoader.loadClass("classloader.Test15");
        System.out.println("class:" + clazz);
        Object object = clazz.newInstance();
    }
}

猜測一下,首先自定義類加載器classLoader通過反射獲取Test15的Class對象,屬於主動使用,會加載Test15,classLoader委託它的父加載器AppClassLoader加載Test15;然後我們通過clazz.newInstance();代碼獲取Test15的實例,調用Test15的構造方法,在Test15的構造方法中創建了Test14的實例,所以同樣加載了Test14,並調用了Test14的構造方法。加上-XX:+TraceClassLoading指令執行代碼,發現運行結果和我們想的是一樣的。

......
[Loaded classloader.Test15 from file:/home/fanxuan/Study/java/jvmStudy/out/production/jvmStudy/]
class:class classloader.Test15
Test15 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
[Loaded classloader.Test14 from file:/home/fanxuan/Study/java/jvmStudy/out/production/jvmStudy/]
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
......

測試代碼二

在上篇博客中,自定義類加載器ClassLoaderTest是有一個path屬性可以自定義類的加載路徑的,我們同樣測試一下,我們將Test14和Test15的class文件放到桌面的classloader文件夾下,然後刪除工程路徑下的class文件,執行一下的測試代碼

public class Test16 {
    public static void main(String[] args) throws Exception {
        test02();
    }
    private static void test02 () throws Exception {
        ClassLoaderTest classLoader = new ClassLoaderTest("classLoader");
        classLoader.setPath("/home/fanxuan/桌面/");
        Class<?> clazz = classLoader.loadClass("classloader.Test15");
        System.out.println("class:" + clazz);
        Object object = clazz.newInstance();
    }
}

按照上節的結果,應該都是ClassLoaderTest加載器加載了Test14和Test15類

class:class classloader.Test15
Test15 is loaded by:classloader.ClassLoaderTest@6d6f6e28
Test14 is loaded by:classloader.ClassLoaderTest@6d6f6e28

接下來,我們重新編譯項目,刪除掉工程目錄下的Test14的calss文件,再次執行代碼

class:class classloader.Test15
Test15 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Exception in thread "main" java.lang.NoClassDefFoundError: classloader/Test14
    at classloader.Test15.<init>(Test15.java:11)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.lang.Class.newInstance(Class.java:442)
    at classloader.Test16.test02(Test16.java:25)
    at classloader.Test16.main(Test16.java:9)
Caused by: java.lang.ClassNotFoundException: classloader.Test14
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 8 more

我們發現結果報錯了,按照我們正常的思維,自定義記載器classLoader委託父加載器AppClassLoader加載Test15,從打印結果可以看出Test15加載成功了,然後創建Test15的實例,加載Test14,因為工程目錄下缺少Test14的class文件,所以AppClassLoader無法加載到Test14,由自定義加載器classLoader自身從桌面加載Test14。但是我們發現加載Test14的報了ClassNotFoundException的錯誤,這是因為在Test15中記載Test14的時候,是以Test15的類加載器AppClassLoader來加載的,AppClassLoader加載不到Test14,它的父加載器擴展類加載器同樣加載不到,擴展類加載器的父加載器啟動類加載器也加載不到,所以報錯ClassNotFoundException

然後,再重新編譯項目,刪除掉工程目錄下的Test15的calss文件,再次執行代碼。根據前文分析的代碼,我們可以很清晰的得出結論:由自定義記載器classLoader加載了Test15,由系統類記載器AppClassLoader加載了Test14。

class:class classloader.Test15
Test15 is loaded by:classloader.ClassLoaderTest@6d6f6e28
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2

測試代碼三

簡單修改下Test14類,在Test14的構造方法中引用Test15的Class對象。

public class Test14 {
    public Test14() {
        System.out.println("Test14 is loaded by:" + this.getClass().getClassLoader());

        System.out.println("Test14:" + Test15.class);
    }
}

執行測試代碼二中的測試代碼Test16,結果如下,沒有任何問題。

class:class classloader.Test15
Test15 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Test14:class classloader.Test15

我們同樣重新編譯項目,刪除掉工程目錄下的Test15的calss文件,再次執行代碼。

class:class classloader.Test15
Test15 is loaded by:classloader.ClassLoaderTest@6d6f6e28
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Exception in thread "main" java.lang.NoClassDefFoundError: classloader/Test15
    at classloader.Test14.<init>(Test14.java:11)
    at classloader.Test15.<init>(Test15.java:11)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.lang.Class.newInstance(Class.java:442)
    at classloader.Test16.test02(Test16.java:25)
    at classloader.Test16.main(Test16.java:9)
Caused by: java.lang.ClassNotFoundException: classloader.Test15
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 9 more

我們發現加載已經完成了,但是程序還是報錯了,是我們剛剛加的System.out.println("Test14:" + Test15.class);代碼報的錯,依然是ClassNotFoundException錯誤。

分析:
Test15由自定義記載器classLoader加載,Test14由系統類記載器AppClassLoader加載。導致程序報錯的是因為命名空間的問題,我們在上一篇博客的結尾簡單介紹了命名空間:每個類加載器都有自己的命名空間,命名空間由該加載器及所有的父加載器所加載的類組成。子加載器所加載的類可以看見父加載器加載的類,但是父加載器所加載的類無法看見子加載器加載的類。Test14是由AppClassLoader加載的,在AppClassLoader的命名空間中沒有Test15的,所以程序報錯了。

命名空間實例分析

測試代碼

新建Entity類用於測試

public class Entity {
    private Entity entity;

    public void setEntity(Object entity) {
        this.entity = (Entity)entity;
    }
}

編寫測試代碼

public class Test17 {
    public static void main(String[] args) throws Exception {
        ClassLoaderTest classLoader1 = new ClassLoaderTest("classLoader1");
        ClassLoaderTest classLoader2 = new ClassLoaderTest("classLoader2");

        Class<?> clazz1 = classLoader1.loadClass("classloader.Entity");
        Class<?> clazz2 = classLoader2.loadClass("classloader.Entity");

        System.out.println(clazz1 == clazz2);

        Object object1 = clazz1.newInstance();
        Object object2 = clazz2.newInstance();

        Method method = clazz1.getMethod("setEntity", Object.class);
        method.invoke(object1, object2);
    }
}

運行程序,System.out.println(clazz1 == clazz2);返回結果為true,都是AppClassLoader加載的,classLoader1加載之後會在AppClassLoader的命名空間中形成緩存,classLoader2加載的時候直接返回命名空間已經存在的Class對象,所以clazz1與clazz2相同。

改造下代碼,將Entity類的class文件copy到桌面文件夾下,刪除工程下的class文件,執行如下代碼

public class Test18 {
    public static void main(String[] args) throws Exception {
        ClassLoaderTest classLoader1 = new ClassLoaderTest("classLoader1");
        ClassLoaderTest classLoader2 = new ClassLoaderTest("classLoader2");

        classLoader1.setPath("/home/fanxuan/桌面/");
        classLoader2.setPath("/home/fanxuan/桌面/");

        Class<?> clazz1 = classLoader1.loadClass("classloader.Entity");
        Class<?> clazz2 = classLoader2.loadClass("classloader.Entity");

        System.out.println(clazz1 == clazz2);

        Object object1 = clazz1.newInstance();
        Object object2 = clazz2.newInstance();

        Method method = clazz1.getMethod("setEntity", Object.class);
        method.invoke(object1, object2);
    }
}

根據前文的介紹,不難推斷System.out.println(clazz1 == clazz2);的運行結果為falseclassLoader1和classLoader2分別加載了Entity類,就是其自身加載的(定義類加載器),在jvm的內存中形成了完全獨立的兩個命名空間,所以clazz1與clazz2不同。而且因為clazz1和clazz2相互不可見,調用了classLoader1命名空間中的方法,傳入了classLoader2命名空間的對象,導致程序拋出了異常。

false
Exception in thread "main" java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at classloader.Test18.main(Test18.java:26)
Caused by: java.lang.ClassCastException: classloader.Entity cannot be cast to classloader.Entity
    at classloader.Entity.setEntity(Entity.java:11)
    ... 5 more

不同類加載器的命名空間關係

  • 同一命名空間內的類是相互可見的
  • 子加載器的命名空間包含所有父加載器的命名空間,由子加載器所加載的類可以看見父加載器加載的類
  • 由父加載器所加載的類無法看見子加載器加載的類
  • 如果兩個加載器之間沒有任何直接或間接的父子關係,那麼它們各自加載的類相互不可見

父親委託機制的好處

在的2.1章節簡單介紹了一下類加載器的父親委託機制,這裏面來總結一下好處

  • 確保Java核心類庫的安全:所有的Java應用都至少會引用java.lang.Object類,也就是說在運行期,java.lang.Object類會被記載到Java虛擬機當中;如果這個加載過程是由Java應用自己的類加載器所完成的,那麼可能會在JVM中存在多個版本的java.lang.Object類,而且這些類還是不兼容的、相互不可見的(因為命名空間的原因)。藉助父親委託機制,Java核心類庫中的類的加載工作都是由啟動類加載器來統一完成的,從而確保了Java應用所使用的都是同一個版本的Java核心類庫,他們之間是互相兼容的。
  • 確保Java核心類庫提供的類不會被自定義的類所替代。
  • 不同的類加載器可以為相同名稱(binary name)的類創建額外的命名空間。相同名稱的類可以並存在Java虛擬機中,只需要用不同的類加載器來加他們即可,不同類加載器所加載的類是不兼容的,這就相當於在Java虛擬機內部創建了一個又一個相互隔離的Java類空間。

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

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

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

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

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