鋰電池再生利用,新創事業 FreeWire 推行動充電車

  特斯拉(Tesla)高調宣布鋰電池儲能系統,其中針對企業用戶的「Powerpack」,100 度電售價 25,000 美元,已將平均儲能成本拉低到相當驚人的每度電 250 美元,一般認為若平均儲能成本降到每度電 100 美元,將引爆能源儲存革命,特斯拉挾 GigaFactory 的威力,正全速逼近這個目標,不過,卻有一個小型新創事業,認為現在就可以做到。   這家新創事業 FreeWire 初期募資金額不過 42.5 萬美元,加上美國海軍資助 50 萬美元,如何能超越家大業大的特斯拉?其實原理也不難,就是採用二手電池。   FreeWire 、日產(Nissan)與 NEC 合資的汽車能源供應公司(Automotive Energy Supply Corporation,AESC)合作,AESC 是僅次於 Panasonic,全球第二大車用鋰電池供應商,市佔率達 21%,2014 年銷售最佳的電動車是 Nissan Leaf,其電池正是由 AESC 供應,Nissan 每個月都會測試電池,每六個月就汰換效能已經衰退的鋰電池,數量以千計,對 Nissan 來說庫存這些二線電池是個麻煩,但這些電池的效能或許已經不不敷電動車所需,拿來做為能源儲存用途卻還很有用。   於是,FreeWire 以新電池六分之一的價格取得這些二手電池,第一步,是取之於電動車用之於電動車,將這些二手電池組裝成總容量 48 度電的行動充電車,專供電動車在本來沒有設置充電座的停車場、機場、企業廠區等處充電,行動充電車可以推到停車場任何一個停車格,幫電動車充電,如此一來,停車場可以省下設置大量充電座的成本,卻能提供身為少數的電動車主充電服務,而這些二手電池在每天充放電循環 2 次的情況下,還可以有 5 年的壽命。  
 

    由於使用二手電池,FreeWire 裝置的每度電成本只有 100 美元,執行長阿卡迪‧索西諾夫(Arcady Sosinov)表示,電池產業界要到 2030 年才能達到的成本目標,他們用二手電池壓低成本,所以現在就已經做到。   阿卡迪‧索西諾夫的野心不只是為電動車行動充電,他認為二手電池的商機相當廣大,同樣的系統也可用來取代柴油發電機,為沒有電力供應之處供電,或是作為備援電力,而鋰電池供電比起柴油發電機有更大的優勢,那就是不會產生噪音與廢氣。如果要在戶外辦一場蚊子電影院,使用鋰電池系統顯然更好,而許多開發中國家的手機基地台因電網不穩定都有備用電源需求,以往這些取代柴油發電機的系統生意由奇異的獨拉松獨佔,如今以二手電池成本之低,也可與之競爭。   更進一步,二手電池系統也可進軍特斯拉正大張旗鼓進入的家庭與企業能源儲存領域,不過,二手電池的發展,也不是只會和特斯拉打對台,因為特斯拉發展電動車也一樣會面臨汰換大量二手電池,這些二手電池若都可再利用製成能源儲存裝置,對特斯拉也是一項利多。   FreeWire 利用二手電池的想法也給能源儲存業界一個啟發,過去鋰電池效能會衰退是產業界的一大問題,但換個方向思考,開啟電池的分級使用,反而可開創許多價格彈性商機。     本文全文授權轉載自《科技新報》─〈〉

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

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

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

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

Salesforce LWC學習(十八) datatable展示 image

本篇參看:

https://developer.salesforce.com/docs/component-library/bundle/lightning-datatable/documentation

https://www.lightningdesignsystem.com/components/data-tables/

我們在salesforce中,經常會使用 listview,標準的 lightning listview會有排序,filter展示chart等等標準功能。當然,某些情況標準搞定不了情況下,我們便需要使用自定義的開發。自定義開發我們就可以使用 lightning-datatable組件。一個 lightning-datatable組件用來展示表格數據,它可以根據數據類型展示每一列。比如一個 email類型的字段會展示一個點開以後是一個 mail:to的超鏈接。默認展示的類型是text類型。那 lightning-datatable有哪些特性呢?

  • 展示和格式化焗油適當類型的列
  • 具有無限滾動行功能
  • 指定的數據類型允許 inline編輯
  • 可以定義header的action
  • 可以定義行級別的action
  • 重置每一列展示的大小
  • 選擇行操作
  • 指定的列通過升序或者降序排列
  • 文字換行和剪切
  • 對行進行編號
  • 設置單元格對齊方式

lightning-datatable有很多屬性,其他的請自行查看文檔,這裏只例舉幾個核心屬性或者方法。比較核心的如下:

  • columns:一組列的object用來定義數據類型,這個object有很多的屬性,其中有幾個必填的配置: label & fieldName & type。分別對應着字段的展示名稱,字段的API name以及字段的類型,不同的字段類型將會自動的轉換成不同的展示形式,默認是text。其他的屬性我們後期會有簡單介紹。
  • data:一組數據用來展示,通常 comulns設置表單的頭以及每個單元列的類型,data設置內容;
  • hide-checkbox-column:標籤用來設定是否展示左側的checkbox,值為true/false,true即隱藏checkbox;
  • selected-rows:用來初始化時展示哪些行是被選中的;
  • key-field:用來指定每行的unique id;
  • getSelectedRows:這個是lightning-datatable提供的方法,用來獲取哪些行用戶選中的。

簡單介紹完畢,下面通過幾點來慢慢帶入datatable的功能。

一. 基礎 Datatable展示數據

demo中展示,我們來看官方提供的一個demo。

dataTableExample1.html:用來展示一個 datatable,我們看到屬性中的data / columns / key-field都是上面描述過的, onrowselection方法為當有行選擇的時候的調用

<template>
    <lightning-datatable
            data={data}
            columns={columns}
            key-field="id"
            onrowselection={getSelectedName}>
    </lightning-datatable>
</template>

 dataTableExample1.js:有兩種方式可以獲取選擇的行信息,demo中有兩個。datatable有一個標準事件rowselection,調用以後可以通過event.detail.

selectedRows獲取選中的行的信息,另外一種就是找到datatable然後調用其getSelectedRows方法。

除此之外,我們看到columns的設置方式,除了 label / fieldName / type這三個基礎信息以外,還可以看到有 typeAttributes 以及 cellAttributes兩種設置。

  • typeAttributes:用於對指定的列的類型格式化dataCell,不同的type可能擁有不同的設置。salesforce針對不同的type可以設置不同的 typeAttributes,這裏不再詳細展開,具體查看文檔;
  • cellAttributes:typeAttributes用於設置針對 type的格式化,cellAttributes通常用於列中附加圖標信息,設置圖標位置等信息。
import { LightningElement } from 'lwc';

const columns = [
     {label: 'Opportunity name', fieldName: 'opportunityName', type: 'text'},
     {label: 'Confidence', fieldName: 'confidence', type: 'percent', cellAttributes:{ iconName: { fieldName: 'trendIcon' }, iconPosition: 'right' }},
     {label: 'Amount', fieldName: 'amount', type: 'currency', typeAttributes: { currencyCode: 'EUR'}},
     {label: 'Contact Email', fieldName: 'contact', type: 'email'},
     {label: 'Contact Phone', fieldName: 'phone', type: 'phone'},
];

const data = [{
                    id: 'a',
                    opportunityName: 'Cloudhub',
                    confidence: 0.2,
                    amount: 25000,
                    contact: 'jrogers@cloudhub.com',
                    phone: '2352235235',
                    trendIcon: 'utility:down'
                },
                {
                    id: 'b',
                    opportunityName: 'Quip',
                    confidence: 0.78,
                    amount: 740000,
                    contact: 'quipy@quip.com',
                    phone: '2352235235',
                    trendIcon: 'utility:up'
                }];

export default class DatatableExample1 extends LightningElement {
    data = data;
    columns = columns;

    getSelectedName(event) {
        //兩種方式獲取選中的行,第一種是使用 event.detail.selectedRows,另外一種是使用querySelector找到 lightning-datatable,然後使用datatable封裝的方法
        //const selectedRows = event.detail.selectedRows;
        const dataTable = this.template.querySelector('lightning-datatable');
        const selectedRows = dataTable.getSelectedRows();
        // Display that fieldName of the selected rows
        for (let i = 0; i < selectedRows.length; i++){
            console.log("You selected: " + selectedRows[i].opportunityName);
        }
    }
}

 簡單展示效果如下:

 二. datatable中展示父表中的字段值

上個demo中簡單介紹了datatable的使用,數據全是寫死的demo,接下來通過一個包含後台的邏輯進行datatable展示數據。

DataTableExampleController:用於獲取 Case表中的相關字段以及其父表的字段

public with sharing class DataTableExampleController {
    @AuraEnabled(cacheable=true)
    public static List<Case> getCaseList(){
        List<Case> caseList = [SELECT Id,CaseNumber,Account.Name,
                                    Priority,Status
                                FROM Case
                                LIMIT 100];
        return caseList;
    }
}

datatableExample2.js:用於展示相關的字段,通過wire adapter獲取後台數據放在data中

import { LightningElement, track, wire } from 'lwc';
import getCaseList from '@salesforce/apex/DataTableExampleController.getCaseList';
const COLUMNS = [
    {label: 'Case Number', fieldName: 'CaseNumber', type: 'text'},
    {label: 'Account Name', fieldName: 'Account.Name', type: 'text'},
    {label: 'Priority', fieldName: 'Priority', type: 'text'},
    {label: 'Status', fieldName: 'Status', type: 'text'}
];
export default class DataTableExample2 extends LightningElement {
    columns = COLUMNS;
    @track datas;

    @wire(getCaseList)
    wiredCaseList({ error, data }) {
        if(data) {
            this.datas = data;
        } else if(error) {
            //TODO
            console.log(JSON.stringify(error));
        }
    }
}

dataTableExample.html:展示datatable

<template>
    <lightning-datatable
            data={datas}
            columns={columns}
            key-field="id"
            >
    </lightning-datatable>
</template>

結果展示:通過下圖我們可以看到,其他的字段可以正常展示,但是父表的數據獲取確實失敗的。

 來剖析一下原因,datatable針對columns的fieldName只支持一級結構的獲取,針對獲取父的方式沒法通過 各種點的方式獲取到,那麼如何獲取呢,查看下面的方式,我們對js的代碼進行一下改動。按照下面的步驟兩步走的修改。

 結果展示:我們可以看到 Account Name列的值也順利的展示出來了,按照這種操作做一個拓展,其實我們也可以去做一些字段間的邏輯操作拼出一個符合我們邏輯的列,不僅僅局限於獲取父的對象值這種簡單操作。

 三. 實現datatable展示 formula類型是圖片的功能

自己看文檔的小夥伴可能發現datatable的columns的type沒有類似 image類型,但是在object field創建時我們很容易創建一些IMAGE的字段,那樣的話使用標準的datatable便無法展示,那要如何操作呢?還好lwc提供了一個自定義類型的操作。首先我們在Case表裡面新增一個formula 字段,展示圖片。

 接下來一步接着一步搞定。

dataTableWithImage.js:這裏需要繼承 LightningDatatable,並且引入 imageRow.html,其用於做template

import LightningDatatable from 'lightning/datatable';
import imageRow from './imageRow.html';
export default class DataTableWithImage extends LightningDatatable {
    static customTypes = {
        image: {
            template: imageRow
        }
    };
}

imageRow.html:默認要求 imageRow需要和 dataTableWithImage在同一個目錄下,如果不在一個目錄,需要改上面的文件目錄信息。

<template>
    <c-data-table-image-template
        url={value}
        >
    </c-data-table-image-template>
</template>

dataTableImageTemplate.html:用來通過 img標籤展示圖片

<template>
    <img src={url} class="image"/>
</template>

dataTableImageTemplate.css:用來設置圖片大小的初始值,這種是一種偷懶的方式,正常應該通過 attribute注入進來指定大小的寬和高。

.image {
  height: 30px;
  width: 30px;
}

dataTableImageTemplate.js

import { LightningElement,api } from 'lwc';

export default class DataTableImageTemplate extends LightningElement {
    @api url;
}

OK,通過上面的這些步驟我們實現和繼承了自定義的datatable組件。接下來是調用操作。我們在class裏面搜索一下Priority_Image__c這個字段,apexClass這裏不再寫。

dataTableExample3.js:這裡有幾個關鍵點。

  • 設置 type為 image類型,image類型是我們上文自定義創建的
  • 對 formula類型進行解析,找到他的src部分。比如針對<img src=”/resource/priority/priority/medium.png” alt=”Priority Flag” border=”0″/>這個字符串,我們需要的是/resource/priority/priority/medium.png這個字符串
import { LightningElement, track, wire } from 'lwc';
import getCaseList from '@salesforce/apex/DataTableExampleController.getCaseList';

const COLUMNS = [
    {label: 'Case Number', fieldName: 'CaseNumber', type: 'text'},
    {label: 'Account Name', fieldName: 'AccountName', type: 'text'},
    {label: 'Priority', fieldName: 'Priority', type: 'text'},
    { label: 'Priority Image',fieldName:'Priority_Image__c',type: 'image' },
    {label: 'Status', fieldName: 'Status', type: 'text'}
];
export default class DataTableExample3 extends LightningElement {
    columns = COLUMNS;
    @track datas;

    @wire(getCaseList)
    wiredCaseList({ error, data }) {
        if(data) {
            //this.datas = data;
            let resultList = [];
            let objectTemp;
            data.forEach(item => {
                objectTemp = Object.assign({},item);
                if(item.Account) {
                    objectTemp.AccountName = item.Account.Name;
                }

                const srcIndex = objectTemp.Priority_Image__c.indexOf('src=');
                if(srcIndex !== -1) {
                    const imgSrcSubstring = objectTemp.Priority_Image__c.substring(srcIndex + 5);
                    objectTemp.Priority_Image__c = imgSrcSubstring.substring(0,imgSrcSubstring.indexOf('"'))
                }
                console.log(JSON.stringify(objectTemp));
                resultList.push(objectTemp);
            });
            this.datas = resultList;
        } else if(error) {
            //TODO
            console.log(JSON.stringify(error));
        }
    }
}

dataTableExample3.html

<template>
    <c-data-table-with-image
                    key-field="id"
                    data={datas}
                    columns={columns}
                    >
                </c-data-table-with-image>
</template>

結果展示:針對不同的Priority展示其對應的formula的圖片。

總結:篇中講了datatable的簡單的應用以及相應的擴展,datatable很強悍,這裏不逐點講述,感興趣的可以自行查看 inline edit,action等操作。篇中有錯誤地方歡迎指出,有不懂的歡迎留言。

後記:工作原因這篇博客準備了好久才成型,不知不覺學了半年的lwc的開發,也整理總結了一些博客供自己和他人學習。前半年的主旋律大部分時間都在學習lwc,後半年的時間大部分會放在考證和學習其他技術,不出意外應該是今年的最後一篇lwc的博文。有其他lwc的問題歡迎留言探討,希望各位salesforce開發者可以養成獨立思考的能力,先思考,在查,最後再問。加油!

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

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

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

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

特斯拉:將調整以符合中國充電標準

美國電動車大廠特斯拉(Tesla)表示,在中國發布全國電動車充電標準後,該公司將修改新生產的車輛,以便用戶可在符合新標準的充電設施,享受充電服務。    特斯拉在中文網站發布公告:「特斯拉將全面支持新國標,修改新生產車輛以符合新國標的規定… 隨著未來幾年中國充電基礎設施的飛速發展,特斯拉用戶將徹底消除對於充電的顧慮。」    特斯拉的充電規格和中國不相容,是消費者不敢購買電動車的一大阻力。不過,中國當局對此尚未提出明確的時間表,電動車充電的新標準何時出爐仍不得而知。

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

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

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

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

氣候變遷衝擊 2050年前全球經濟損失恐達241兆元

摘錄自2019年11月20日中央通訊社綜合報導

最新分析報告顯示,隨著越來越多的旱澇災情和農作物歉收,危及經濟成長,威脅基礎建設,氣候變遷恐直接造成2050年前全球經濟損失7.9兆美元(約新台幣241兆元)。

英國經濟學人資訊社(EIU)今天(20日)公布氣候變遷韌性指數(Climate Change Resilience Index),發現以當前趨勢來看,氣溫暖化帶來的衝擊在2050年以前,將讓全球經濟成長下滑3%。這項指數用來衡量全球82大經濟體的準備程度。

氣候變遷引發的極端氣候事件頻傳,這項報告評估各國暴露在氣候變遷帶來的損失,結果發現非洲地區風險最高,區域國內生產毛額(GDP)恐因此萎縮4.7%。

世界最大經濟體美國被認為是受到衝擊程度最小的國家之一。但經濟學人資訊社提到,美國總統川普的政策代表在對抗氣候變遷戰爭中「短暫地倒退」。

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

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

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

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

Linux系統如何使用Fuser命令

本文不再更新,可能存在內容過時的情況,實時更新請訪問原地址:Linux系統如何使用Fuser命令;

什麼是Fuser命令?

fuser命令是一個非常聰明的unix實用程序,用於查找正在使用某個文件、目錄或socket的進程。 它還提供有關擁有該進程的用戶和訪問類型的信息。。fuser工具显示了使用指定文件或文件系統的每個進程的進程ID(PID)。

安裝

如果你的精簡版運行fuser提示如下信息:

-bash: fuser: command not found

請執行如下命令安裝:

[winbert@winbert-server ~]$ sudo yum -y install psmisc

如何使用fuser命令?

man命令可用於查看任何命令的幫助手冊,但是學習新知識(尤其是linux命令)的最佳方法是通過閱讀真實的示例,並且不斷地在終端中鍵入命令。 在終端中運行以下命令,以獲取有關fuser實用程序的使用選項的信息。

[winbert@winbert-server ~]$ fuser
No process specification given
Usage: fuser [-fMuvw] [-a|-s] [-4|-6] [-c|-m|-n SPACE] [-k [-i] [-SIGNAL]] NAME...
       fuser -l
       fuser -V
Show which processes use the named files, sockets, or filesystems.

  -a,--all              display unused files too
  -i,--interactive      ask before killing (ignored without -k)
  -k,--kill             kill processes accessing the named file
  -l,--list-signals     list available signal names
  -m,--mount            show all processes using the named filesystems or block device
  -M,--ismountpoint     fulfill request only if NAME is a mount point
  -n,--namespace SPACE  search in this name space (file, udp, or tcp)
  -s,--silent           silent operation
  -SIGNAL               send this signal instead of SIGKILL
  -u,--user             display user IDs
  -v,--verbose          verbose output
  -w,--writeonly        kill only processes with write access
  -V,--version          display version information
  -4,--ipv4             search IPv4 sockets only
  -6,--ipv6             search IPv6 sockets only
  -                     reset options

  udp/tcp names: [local_port][,[rmt_host][,[rmt_port]]]

如何查看使用某個目錄的進程

fuser序可以與-v選項一起使用,該選項以詳細模式運行該工具。 verbose選項用於在計算機屏幕上生成詳細輸出,因此用戶可以實時查看實用程序正在執行的操作。

[winbert@winbert-server ~]$ fuser -v .
                     USER        PID ACCESS COMMAND
/home/winbert:       winbert    1435 ..c.. bash

上面的輸出显示,以詳細模式運行時,fuser會提供有關USERPIDACCESSCOMMAND的信息。 ACCESS下的c字符表示訪問類型,表示“當前目錄”。 訪問類型很多,例如e(正在運行的可執行文件),r(根目錄),f(打開文件。在默認显示模式下省略f),F(用於寫入的打開文件,在默認显示模式下省略F)和 m(mmap文件或共享庫)。

查看使用你tcp或udp套接字的進程?

有時您需要使用TCP和UDP套接字查找進程。 為了查找這些進程,需要使用-n選項。 -n選項用於選擇相應的名稱空間。

[root@huidukongjian-h4 docker]# fuser -v -n tcp 80
                     USER        PID ACCESS COMMAND
80/tcp:              root      27411 F.... docker-proxy

默認情況下,fuser將同時在IPv6和IPv4套接字中查找,但是可以使用-4-6選項更改默認選項。 -4選項代表IPv4-6選項代表IPv6。 請注意,fuser僅將PID輸出到stdout,其他所有內容都發送到stderr。

fuser -v -n tcp 80命令的結果显示,使用docker的進程的進程ID為27411,而用於啟動該進程的命令為docker-proxy。 進程ID(PID)可以以多種方式使用,其中之一是進程終止。 與PID一起使用時,kill命令根據該進程ID終止進程。 fuser還可用於終止訪問特定文件的進程。 在以下命令中,-k選項用於終止正在使用在端口123上運行的tcp偵聽器的進程。為確保用戶不會殺死錯誤的進程,使用-i選項詢問用戶是否 在終止進程之前進行確認。

fuser -k  123/tcp

使用帶有-i選項的fuser -k命令在終止進程之前要求用戶進行確認。 用戶可以用y回答“是”,或者用N回答不殺死進程。

fuser -i -k 123/tcp
123/tcp:             12216
Kill process 12216 ? (y/N)
Use The -6 Option To Look For IPv6 Sockets.

以下命令以詳細模式使用fuser,並嘗試查找在端口123上運行的IPv6套接字。

fuser -v -n tcp -6 123

查找佔用某個文件系統的進程

-m選項可與fuser命令一起使用,以查找訪問文件文件系統上文件的進程。 此選項需要文件名作為輸入參數。 -m選項非常有用,尤其是當用於發現正在訪問文件系統的進程並標識要殺死的進程時。

以下命令显示所有訪問“ example.txt”所在的文件系統的進程。 仔細查看-m選項如何與fuser一起使用。

[root@huidukongjian-h4 docker]# fuser -v -m data/v2/config.json 
                     USER        PID ACCESS COMMAND
/root/docker-v2/data/v2/config.json:
                     root     kernel mount /
                     root          1 .rce. systemd
                     root          2 .rc.. kthreadd
                     root          3 .rc.. rcu_gp
                     root          4 .rc.. rcu_par_gp
                     root          6 .rc.. kworker/0:0H-kbl
                     root          8 .rc.. mm_percpu_wq
                     root          9 .rc.. ksoftirqd/0
                     root         10 .rc.. rcu_sched
                     root         11 .rc.. migration/0
                     root         12 .rc.. watchdog/0
                     root         13 .rc.. cpuhp/0
                     root         16 .rc.. netns
                     root         17 .rc.. kauditd
                     root         18 .rc.. khungtaskd
                     root         19 .rc.. oom_reaper
                     root         20 .rc.. writeback
                     root         21 .rc.. kcompactd0
                     root         22 .rc.. ksmd
                     root         23 .rc.. khugepaged
                     root         24 .rc.. crypto
                     root         25 .rc.. kintegrityd
                     root         26 .rc.. kblockd
                     root         27 .rc.. tpm_dev_wq
                     root         28 .rc.. md
                     root         29 .rc.. edac-poller
                     root         30 .rc.. watchdogd
                     root         42 .rc.. kswapd0
                     root         93 .rc.. kthrotld
                     root         94 .rc.. acpi_thermal_pm
                     root         95 .rc.. kmpath_rdacd
                     root         96 .rc.. kaluad
                     root         97 .rc.. ipv6_addrconf
                     root         98 .rc.. kstrp
                     root        326 .rc.. scsi_eh_0
                     root        327 .rc.. scsi_tmf_0
                     root        329 .rc.. kworker/0:1H-kbl
                     root        361 .rc.. ata_sff
                     root        363 .rc.. scsi_eh_1
                     root        365 .rc.. scsi_tmf_1
                     root        366 .rc.. scsi_eh_2
                     root        367 .rc.. scsi_tmf_2
                     root        387 .rc.. xfsalloc
                     root        390 .rc.. xfs_mru_cache
                     root        391 .rc.. xfs-buf/vda1
                     root        394 .rc.. xfs-data/vda1
                     root        395 .rc.. xfs-conv/vda1
                     root        396 .rc.. xfs-cil/vda1
                     root        397 .rc.. xfs-reclaim/vda
                     root        398 .rc.. xfs-log/vda1
                     root        399 .rc.. xfs-eofblocks/v
                     root        400 .rc.. xfsaild/vda1
                     root        486 .rce. systemd-journal
                     rpc         541 .rce. rpcbind
                     root        543 Frce. auditd
                     root        545 .rce. sedispatch
                     root        558 .rc.. rpciod
                     root        559 .rc.. kworker/u3:0
                     root        561 .rc.. xprtiod
                     root        582 Frce. sssd
                     polkitd     585 .rce. polkitd
                     root        589 .rce. rngd
                     dbus        593 frce. dbus-daemon
                     chrony      612 .rce. chronyd
                     root        652 Frce. sssd_be
                     root        668 Frce. sssd_nss
                     root        671 .rc.. ttm_swap
                     root        672 .rc.. nfit
                     root        675 frce. systemd-logind
                     root        683 Frce. gssproxy
                     root        740 frce. NetworkManager
                     root        743 Frce. tuned
                     root        814 frce. systemd-udevd
                     root        889 frce. sshd
                     root        890 Frce. rsyslogd
                     root        895 frce. agetty
                     root        898 frce. crond
                     root        899 frce. agetty
                     root      21821 .rc.. kworker/u2:0-flu
                     root      25475 frce. sshd
                     root      25480 .rce. systemd
                     root      25485 frce. (sd-pam
                     root      25491 frce. sshd
                     root      25492 frce. bash
                     root      25705 Frce. containerd
                     root      25706 Frce. dockerd
                     root      26375 .rc.. kworker/u2:1-eve
                     root      27251 Fr.e. containerd-shim
                     root      27267 F...m v2
                     root      27273 Fr.e. containerd-shim
                     root      27295 ....m sh
                     root      27400 .rce. docker-proxy
                     root      27411 .rce. docker-proxy
                     root      27416 Fr.e. containerd-shim
                     root      27432 ....m sh
                     root      27478 ....m sh
                     root      27479 F...m nginx
                     root      27480 ....m sleep
                     (unknown)  27481 F...m nginx
                     root      27561 ....m sleep
                     root      27705 .rc.. kworker/0:0-xfs-
                     root      27765 .rc.. kworker/0:1-xfs-
                     root      27836 .rc.. kworker/0:2-even
                     root      27860 frce. sshd
                     root      27883 frce. sshd
                     sshd      27884 frce. sshd

fuser還可用於將特定指令發送到某個進程。 當與-k選項一起使用時,fuser命令將KILL指令發送給進程。 有很多指令可以發送給運行中的進程,-l選項有助於查找可以與fuser一起使用的指令列表。

[root@huidukongjian-h4 docker]# fuser -l
HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT
CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH POLL PWR SYS

本文不再更新,可能存在內容過時的情況,實時更新請訪問原地址:Linux系統如何使用Fuser命令;

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

【其他文章推薦】

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

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

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

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

※別再煩惱如何寫文案,掌握八大原則!

歐洲各國豪雨不斷 洪水土石流頻傳

摘錄自2019年11月27日公視報導

美澳野火肆虐,在歐洲則是飽受洪災侵襲,包括義大利、法國和希臘,當地從上個週末以來就豪雨不斷;各地接連發生洪水和土石流災情,至少已經傳出有九人死亡。

有的汽車卡在樹上,有的掉進泥池裡,所有東西都被大水沖得四散各地,連路面也跟著崩塌毀損,每戶民宅裡外都是一片狼藉。這是希臘西部這幾天遭受暴雨襲擊過後的景象,面對天災,居民有苦難言。

當地居民說,「水勢洶洶而來,當我們呼叫人在地下室的孩子時,什麼東西都沒有了,門啊、窗啊,洗衣機都在庭院裡了,你去那邊看看庭院的狀況,原本停了五台車,現在一台也不剩。」類似的豪雨災情,同樣出現在義大利北部,靠近山區的一座高架橋不敵洪水與土石流,應聲斷裂、坍塌,所幸目前沒有發現人員傷亡。

另一個為強降雨所苦的地區是法國南部,其中,瓦爾省境內受到洪患影響最大的幾座城鎮,短短48小時之內就累積了三個月的降雨量。許多地方河川潰堤,導致嚴重淹水,而等到星期一部分地區水位退去之後,有4500個住戶停電。

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

【其他文章推薦】

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

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

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

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

※別再煩惱如何寫文案,掌握八大原則!

日本第一例!技術員確診人猴共通「疱疹B病毒感染症」 出現發燒、頭痛症狀

摘錄自2019年11月29日ETtoday綜合報導

日本鹿兒島市28日傳出,「新日本科學」公司鹿兒島市動物實驗設施內,一名技術員被診斷出患有「疱疹B病毒感染症」,是日本境內第一例,而這個相當罕見的病症,在全球僅有約50例確診。

根據台灣衛生福利部疾病管制署網站解釋,疱疹B病毒為人畜共通傳染性病原體,會對感染者的中樞神經系統進行破壞。疱疹B病毒於1932年在美國出現第一例,研究人員B博士(Dr. B)當時被一隻看起來相當健康的恆河猴咬傷,15天後便因急性腦脊髓炎死亡,病毒的名稱也採B博士名字命名為「疱疹B病毒」。疱疹B病毒並無特別季節變化,一年四季的傳染能力同樣活躍。

日本《讀賣新聞》、《中央社》報導,受託開發醫藥品的「新日本科學公司」總社位於東京,並在鹿兒島市設有一處研究設施;一名實驗業務助理在對猴子進行安全性調查時,不慎感染了疱疹B病毒感染症(Herpesvirus B Infection),今年2月出現頭痛、發燒等症狀,但直到8月底轉願接受基因檢查,才在11月上旬被驗出確診。

這類流行於獼猴、日本獼猴等獼猴屬猿猴間的病毒不會經由空氣傳染,主要透過抓、咬受傷後進入人體,潛伏期約2至5週,發病會出現發燒、麻痺等症狀。

鹿兒島市和新日本科學公司並未對外公布實驗業務助理的姓名,也未透露身體狀況、性別和年齡。報導指出,該名技術員平常直接接觸猿猴的機會很少,就診時也沒有被猿猴抓、咬的痕跡,目前正進一步調查染病途徑。

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

【其他文章推薦】

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

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

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

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

※別再煩惱如何寫文案,掌握八大原則!

沒想到,這麼簡單的線程池用法,深藏這麼多坑!

又又又踩坑了

生產有個對賬系統,每天需要從渠道端下載對賬文件,然後開始日終對賬。這個系統已經運行了很久,前两天突然收到短信預警,沒有獲取渠道端對賬文件。

ps:對賬系統詳細實現方式:對賬系統設計與實現

本以為又是渠道端搞事情,上去一排查才發現,所有下載任務都被阻塞了。再進一步排查源碼,才發現自己一直用錯了線程池某個方法。

由於線程創建比較昂貴,正式項目中我們都會使用線程池執行異步任務。線程池,使用池化技術保存線程對象,使用的時候直接取出來,用完歸還以便使用。

雖然線程池的使用非常方法非常簡單,但是越簡單,越容易踩坑。細數一下,這些年來因為線程池導致生產事故也有好幾起。

所以今天,小黑哥就針對線程池的話題,給大家演示一下怎麼使用線程池才會踩坑。

希望大家看完,可以完美避開這些坑~

先贊后看,養成習慣。微信搜索「程序通事」,關注就完事了!

慎用 Executors 組件

Java 從 JDK1.5 開始提供線程池的實現類,我們只需要在構造函數內傳入相關參數,就可以創建一個線程池。

不過線程池的構造函數可以說非常複雜,就算最簡單的那個構造函數,也需要傳入 5 個參數。這對於新手來說,非常不方便哇。

也許 JDK 開發者也考慮到這個問題,所以非常貼心給我們提供一個工具類 Executors,用來快捷創建創建線程池。

雖然這個工具類使用真的非常方便,可以少寫很多代碼,但是小黑哥還是建議生產系統還是老老實實手動創建線程池,慎用Executors,尤其是工具類中兩個方法 Executors#newFixedThreadPoolExecutors#newCachedThreadPool

如果你圖了方便使用上述方法創建了線程池,那就是一顆定時炸彈,說不準那一天生產系統就會。

我們來看兩個,看下這個這兩個方法會有什麼問題。

假設我們有個應用有個批量接口,每次請求將會下載 100w 個文件,這裏我們使用 Executors#newFixedThreadPool批量下載。

下面方法中,我們隨機休眠,模擬真實下載耗時。

為了快速復現問題,調整 JVM 參數為 -Xmx128m -Xms128m

private ExecutorService threadPool = Executors.newFixedThreadPool(10);

/**
 * 批量下載對賬文件
 *
 * @return
 */
@RequestMapping("/batchDownload")
public String batchDownload() {
    
    // 模擬下載 100w 個文件
    for (int i = 0; i < 1000000; i++) {
        threadPool.execute(() -> {
            // 隨機休眠,模擬下載耗時
            Random random = new Random();
            try {
                TimeUnit.SECONDS.sleep(random.nextInt(100));
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
    }

    return "process";
}

程序運行之後,多請求幾次這個批量下載方法,程序很快就會 OOM

查看 Executors#newFixedThreadPool源碼,我們可以看到這個方法創建了一個默認的 LinkedBlockingQueue 當做任務隊列。

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());
}

這個問題槽點就在於 LinkedBlockingQueue,這個隊列的默認構造方法如下:

/**
 * Creates a {@code LinkedBlockingQueue} with a capacity of
 * {@link Integer#MAX_VALUE}.
 */
public LinkedBlockingQueue() {
    this(Integer.MAX_VALUE);
}

創建 LinkedBlockingQueue 隊列時,如果我們不指定隊列數量,默認數量上限為 Integer.MAX_VALUE。這麼大的數量,我們簡直可以當做無界隊列了。

上面我們使用 newFixedThreadPool,我們僅使用了固定數量的線程下載。如果線程都在執行任務,線程池將會任務加入任務隊列中。

如果線程池執行任務過慢,任務將會一直堆積在隊列中。由於我們隊列可以認為是無界的,可以無限制添加任務,這就導致內存佔用越來越高,直到 OOM 爆倉。

ps:線程池基本工作原理

下面我們將上面的例子稍微修改一下,使用 newCachedThreadPool 創建線程池。

程序運行之後,多請求幾次這個批量下載方法,程序很快就會 OOM ,不過這次報錯信息與之前信息與之前不同。

從報錯信息來看,這次 OOM 的主要原因是因為無法再創建新的線程。

這次看下一下 newCachedThreadPool 方法的源碼,可以看到這個方法將會創建最大線程數為 Integer.MAX_VALUE 的的線程池。

由於這個線程池使用 SynchronousQueue 隊列,這個隊列比較特殊,沒辦法存儲任務。所以默認情況下,線程池只要接到一個任務,就會創建一個線程。

一旦線程池收到大量任務,就會創建大量線程。Java 中的線程是會佔用一定的內存空間 ,所以創建大量的線程是必然會導致 OOM

先贊后看,養成習慣。微信搜索「程序通事」,關注就完事了!

復用線程池

由於線程池的構造方法比較複雜,而 Executors 創建的線程池比較坑,所以我們有個項目中自己封裝了一個線程池工具類。

工具類代碼如下:

public static ThreadPoolExecutor getThreadPool() {
    // 為了快速復現問題,故將線程池 核心線程數與最大線程數設置為 100
    return new ThreadPoolExecutor(100, 100, 60, TimeUnit.SECONDS, new LinkedBlockingDeque<>(200));
}

項目代碼中這樣使用這個工具類:

@RequestMapping("/batchDownload")
public String batchDownload() {
    ExecutorService threadPool = ThreadPoolUtils.getThreadPool();

    // 模擬下載 100w 個文件
    for (int i = 0; i < 100; i++) {
        threadPool.execute(() -> {
            // 隨機休眠,模擬下載耗時
            Random random = new Random();
            try {
                TimeUnit.SECONDS.sleep(random.nextInt(100));
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
    }

    return "process";
}

使用 WRK 工具對這個接口同時發起多個請求,很快應用就會拋出 OOM

每次請求都會創建一個新的線程池執行任務,如果短時間內有大量的請求,就會創建很多的線程池,間接導致創建很多線程。從而導致內存佔盡,發生 OOM 問題。

這個問題修復辦法很簡單,要麼工具類生成一個單例線程池,要麼項目代碼中復用創建出來的線程池。

Spring 異步任務

上面代碼中我們都是自己創建一個線程池執行異步任務,這樣還是比較麻煩。在 Spring 中, 我們可以在方法上使用 Spring 註解 @Async,然後執行異步任務。

代碼如下:

@Async
public void async() throws InterruptedException {
    log.info("async process");
    Random random = new Random();
    TimeUnit.SECONDS.sleep(random.nextInt(100));
}

不過使用 Spring 異步任務,我們需要自定義線程池,不然大量請求下,還是有可能發生 OOM 問題。

這是原因主要是 Spring 異步任務默認使用 Spring 內部線程池 SimpleAsyncTaskExecutor

這個線程池比較坑爹,不會復用線程。也就是說來一個請求,將會新建一個線程。

所以如果需要使用異步任務,一定要使用自定義線程池替換默認線程池。

如果使用 XML 配置,我們可以增加如下配置:

<task:executor id="myexecutor" pool-size="5"  />
<task:annotation-driven executor="myexecutor"/>

如果使用註解配置,我們需要設置一個 Bean:

@Bean(name = "threadPoolTaskExecutor")
public Executor threadPoolTaskExecutor() {
    ThreadPoolTaskExecutor executor=new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(5);
    executor.setMaxPoolSize(10);
    executor.setThreadNamePrefix("test-%d");
    // 其他設置
    return new ThreadPoolTaskExecutor();
}

然後使用註解時指定線程池名稱:

@Async("threadPoolTaskExecutor")
public void xx() {
    // 業務邏輯
}

如果是 SpringBoot 項目,從本人測試情況來看,默認將會創建核心線程數為 8,最大線程數為 Integer.MAX_VALUE,隊列數也為 Integer.MAX_VALUE線程池。

ps:以下代碼基於 Spring-Boot 2.1.6-RELEASE,暫不確定 Spring-Boot 1.x 版本是否也是這種策略,熟悉的同學的,也可以留言指出一下。

雖然上面的線程池不用擔心創建過多線程的問題,不是還是有可能隊列任務過多,導致 OOM 的問題。所以還是建議使用自定義線程池嗎,或者在配置文件修改默認配置,例如:

spring.task.execution.pool.core-size=10
spring.task.execution.pool.max-size=20
spring.task.execution.pool.queue-capacity=200

Spring 相關踩坑案例: Spring 定時任務突然不執行

線程池方法使用不當

最後再來說下文章開頭的我踩到的這個坑,這個問題主要是因為理解錯這個方法。

錯誤代碼如下:

// 創建線程池
ExecutorService threadPool = ...
List<Callable<String>> tasks = new ArrayList<>();
// 批量創建任務
for (int i = 0; i < 100; i++) {
    tasks.add(() -> {
        Random random = new Random();
        try {
            TimeUnit.SECONDS.sleep(random.nextInt(100));
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "success";
    });
}
// 執行所有任務
List<Future<String>> futures = threadPool.invokeAll(tasks);
// 獲取結果
for (Future<String> future : futures) {
    try {
        future.get();
    } catch (ExecutionException e) {
        e.printStackTrace();
    }
}

上面代碼中,使用 invokeAll執行所有任務。由於這個方法返回值為 List<Future<T>>,我誤以為這個方法如 submit一樣,異步執行,不會阻塞主線程。

實際上從源碼上,這個方法實際上逐個調用 Future#get獲取任務結果,而這個方法會同步阻塞主線程。

一旦某個任務被永久阻塞,比如 Socket 網絡連接位置超時時間,導致任務一直阻塞在網絡連接,間接導致這個方法一直被阻塞,從而影響後續方法執行。

如果需要使用 invokeAll 方法,最好使用其另外一個重載方法,設置超時時間。

總結

今天文章通過幾個例子,給大家展示了一下線程池使用過程一些坑。為了快速復現問題,上面的示例代碼還是比較極端,實際中可能並不會這麼用。

不過即使這樣,我們千萬不要抱着僥倖的心理,認為這些任務很快就會執行結束。我們在生產上碰到好幾次事故,正常的情況執行都很快。但是偶爾外部程序抽瘋,返回時間變長,就可能導致系統中存在大量任務,導致 OOM

最後總結一下幾個線程池幾個最佳實踐:

第一,生產系統慎用 Executors 類提供的便捷方法,我們需要自己根據自己的業務場景,配置合理的線程數,任務隊列,拒絕策略,線程回收策略等等,並且一定記得自定義線程池的命名方式,以便於後期排查問題。

第二,線程池不要重複創建,每次都創建一個線程池可能比不用線程池還要糟糕。如果使用其他同學創建的線程池工具類,最好還是看一下實現方式,防止自己誤用。

第三,一定不要按照自己的片面理解去使用 API 方法,如果把握不準,一定要去看下方法上註釋以及相關源碼。

歡迎關注我的公眾號:程序通事,獲得日常乾貨推送。如果您對我的專題內容感興趣,也可以關注我的博客:studyidea.cn

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

【其他文章推薦】

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

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

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

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

※別再煩惱如何寫文案,掌握八大原則!

冰河期大氣中二氧化碳濃度為何比較低? 關鍵證據找到了

編譯:嚴融怡(胡適國小創思組科任教師)

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

【其他文章推薦】

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

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

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

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

※別再煩惱如何寫文案,掌握八大原則!

儲電技術與成本 抑制印度煤電成長的關鍵 | 解讀《 2019年世界能源展望》報告2/3

環境資訊中心外電;姜唯 翻譯;林大利 審校;稿源:Carbon Brief 前言:國際能源署(IEA)11月13日發表2019年《世界能源展望》報告。810頁報告的特點在於「承諾政策情境」(Stated Policies Scenario, STEPS),反映政府已經說出口的政策的效果──風能和太陽能的激增將使再生能源滿足全球能源需求的大部分成長。但是煤炭的平穩發展,加上對石油和天然氣的需求不斷增加,全球排放量在到2040年的展望期內將繼續上升。 相對地,報告的「永續發展情境」(Sustainable Development Scenario, SDS)描繪出有50%機率將升溫限制在1.65°C內所需的條件,IEA表示這是「完全符合巴黎協定」的情況──SDS需要投資「大量重新分配」,從化石燃料轉向效率和再生能源、淘汰全球約一半的燃煤電廠,以及全球經濟的其他變化。

二氧化碳排放量

()在STEPS之下,全球來自能源的碳排放量將在2018年創紀錄後繼續上升,本世紀很可能升溫2.7°C以上。 下表中的黑色虛線表示此排放軌跡。

相反地,SDS(紅色粗線)之下碳排迅速下降,比2010年還下降17%,2040年下降48%,2050年下降68%。IEA說,如此可在2070年實現淨零排放,並且有50%的機會將升溫限制在1.65°C,或66%的機會停在1.8°C。

這條軌跡的積極度比大多數1.5°C途徑要低,升溫沒有或是僅一小段時間超標(下圖中的黃線)。 政府間氣候變遷專門委員會(IPCC)在其1.5°C特別報告中表示,1.5°C途徑需要在2030年將碳排降至2010年水平的45%,並在2050年達到淨零。

過去(實線)和未來各種不同情境下,來自能源和工業的全球二氧化碳排放量:IEA STEPS(黑色虛線)、IEA SDS(粗紅線)、IPCC升溫1.5℃內途徑,沒有或有限的升溫度超標(細黃線)、IPCC升溫超過1.5C途徑(藍色)以及IPCC升溫2C途徑(灰色)。低於零的值表示負排放,即來自能源和工業的二氧化碳增加量少於移除量,這裡主要是指有碳捕獲和儲存(BECCS)的生物能。資料來源:國際能源署《 2019年世界能源展望》和Carbon Brief對IPCC 1.5℃暖化特別報告的簡要分析。圖片由Carbon Brief用Highcharts繪製。

根據IEA資料,SDS「使全球氣溫上升控制在遠低於2°C……並力求控制在1.5°C以內,完全符合《巴黎協定》目標」。還提供了兩種表現可以超越SDS,同時升溫保持在1.5°C以下的選擇。

「力求」不一定是實現目標,而是朝著目標前進,或者是非常接近1.5°C-只要有額外的行動。

除了WEO中心觀點STEPS外,巴黎協定中所謂的「非常接近」也是飽受非政府組織、科學家、商業團體和其他組織批評的語言。他們今年四月寫信呼籲IEA模擬出有66%機率將升溫限制在1.5°C的情境。

這封信的其中一位作者、倫敦帝國理工學院格蘭瑟姆研究所氣候變遷和環境講師羅傑爾(Joeri Rogelj)博士說,SDS和1.5°C不一致,和《巴黎協定》也有些面向不同。

羅傑爾是IPCC 1.5°C特別報告第二章的協調主要作者,也是IPCC即將發布的第六次評估報告中第一工作組的主要作者。

他告訴Carbon Brief,巴黎協定的「力求1.5°C」至少有兩種可能的解釋,一種是將峰值升溫限制在1.5°C,另一種是可以超過再降回。「把錯過目標納入計畫當中,不能合理解釋成完全符合《巴黎協定》,」羅傑爾說。

他還指出了協定的第4條,致力於在人為碳排放源與所有溫室氣體匯之間達到「平衡」。要實現這個目標可能需要淨負​碳排​,SDS沒有達成這一點的詳細途徑。

負碳排可以透過技術解決方案實現,如帶有碳捕集與封存的生物能源(BECCS),也可透過自然氣候解決方案達成,如綠化。

IEA表示,負排放確實是SDS之下達成1.5°C的一種方法,總共需要清除大約3000億噸的二氧化碳(GtCO2)才能彌補這個差距。然而IEA也承認,大規模部署負碳排設備的永續性和可交付性的確存在隱憂。

WEO說:

考慮到負排放技術的問題,構建一個超越SDS、2050年實現零碳排放,並有50%的機率將升溫限制在1.5°C,而無需依賴淨負碳排的情境是有可能的。

(這個情境已經有人做出,收錄在IPCC的1.5°C報告和上圖中。)

IEA表示,要超越SDS,全世界必須正面對抗那些最困難的領域,如航空、重工業和建築供熱,包括全面性的建築改造、工業過程新技術的開發和改造。

IEA表示,這「不只是擴大SDS中的變革而已」,而是要「面對非常困難且難以克服的挑戰」,有一些領域需要社會大眾的接受度和行為改變:

「這不是能源業內部就能做到的事,而是整個社會的任務……需要跨非常多領域進行大規模變革,這將直接影響幾乎每個人的生活。」

雖然有點挑戰性,但如果IEA能建構出1.5°C情境,政策規劃人員可以參考IEA模型來瞭解各種能源和氣候選擇。隨著各國政府根據《巴黎協定》重新考慮其氣候承諾,並在2020年推出新一輪的國家自主減排計畫,這個參考資料將顯得很重要。

煤炭的變化

報告內有去年版本至今的各種變動,反映相對於基準年的變化-2018年需求增加力道異常強勁-以及新增或修訂的政策。

IEA再次下調了STEPS下的煤炭需求前景,如下圖所示(紅線)。但是煤炭近期前景提高了,部分原因是中國重新依賴高污染產業來支撐增長緩慢。

全球煤炭需求歷史(黑線,百萬噸石油當量)和IEA前一版中心觀點情境的未來成長(藍色色塊)。今年的STEPS以紅色標示,SDS以黃色標示。資料來源:國際能源署《 2019年世界能源展望》和前一版報告。Carbon Brief使用Highcharts繪製。

照STEPS的計畫和政策,儘管近期需求有所增長,今年燃煤用量將會低於2014年的峰值,但仍遠高於SDS之下、暖化遠低於2°C途徑的水準(上圖黃線)。

STEPS之下,美國和歐盟等已開發經濟體煤炭用量快速下降,但印度需求增長是保持全球煤炭用量穩定的關鍵因素之一。

印度這波成長的部分原因是大量新火力發電廠興建中,到2040年將打造出232GW的容量,成長一倍,佔全球新增容量的1/3。

IEA表示,如果電池儲存成本的下降速度快於預期,印度的煤電容量成長將被「大幅削減」。 IEA表示,太陽能和廉價的儲存技術可以「重塑印度電力結構的演變」,並提供「非常引人注目的經濟和環境主張」。

印度的高壓電塔。照片來源: 。

值得注意的另一點是,印度目前燃煤容量只有85GW,IEA預計的新燃煤容量卻高達232GW,其中有1/4已經被凍結多年。

自2010年以來,由於廉價再生能源的競爭、公用事業公司財務困境和公眾的反對,有額外510GW的新煤電廠計畫被取消。

此外,印度政府一再高估了電力需求的增長,現有煤電容量的運行時間不到2/3。2019年至今的數據顯示,印度煤炭發電量可能正在下降。

印度政府最近宣布了一個相當積極的目標,太陽能、風能和生質能的容量要達到450GW,最快2030年達成。IEA的STEPS到2030年僅增加344GW。根據近期Carbon Brief的分析,如果能夠達到這個目標,那麼風能、太陽能和其他低碳能源可以在不增加新煤電的情況下,滿足日益增長的需求。(2/3,未完待續)

‘Profound shifts’ underway in energy system, says IEA World Energy Outlook (2/3) by Simon Evans

CO2 emissions

In the STEPS, global CO2 emissions from energy would continue to rise from the they reached in 2018, putting the world on track for upwards of 2.7C of warming this century. This emissions trajectory is shown with the dashed black line in the chart, below.

In contrast, CO2 declines quickly in the SDS (thick red line) to 17% below 2010 levels by 2030, 48% by 2040 and 68% by 2050. According to the IEA, this is “on course for net-zero emissions by 2070” and corresponds to a 50% likelihood of limiting warming to 1.65C, or a 66% chance of 1.8C.

This trajectory is less ambitious than most pathways to 1.5C with no or limited overshoot (yellow lines, below). In its on 1.5C, the (IPCC) said this would need CO2 to fall 45% below 2010 levels by 2030 and to net-zero by 2050.

Global CO2 emissions from energy and industrial processes in the past (solid black line) and under a range of different scenarios for the future: IEA STEPS (dashed black); IEA SDS (thick red line); IPCC pathways limiting warming to 1.5C this century with no or limited temperature overshoot (thin yellow lines); pathways to 1.5C with high overshoot (blue); and IPCC 2C pathways (grey). Values below zero indicate negative emissions, where residual CO2 from energy and industry is more than offset by removals, here primarily bioenergy with carbon capture and storage (BECCS). Source: IEA and Carbon Brief analysis of the for the IPCC of warming. Chart by Carbon Brief using .

According to the IEA, the SDS charts “a path fully aligned with the by holding the rise in global temperatures to ‘well below 2C…and pursuing efforts to limit [it] to 1.5C’”. It also offers two options for going beyond the SDS to keep warming below 1.5C.

This form of words implies either that “pursue” means to head towards a goal, without necessarily reaching it, or that the SDS is aligned with 1.5C – so long as it is accompanied by additional action.

Along with the WEO’s central focus on the STEPS pathway, the statement on Paris “alignment” is at the heart of from a group of NGOs, scientists, business groups and others. In an , they called for the IEA to develop a scenario with a 66% chance of limiting warming to 1.5C.

One of the letter’s authors, , a lecturer in climate change and the environment at the , says the SDS is “inconsistent with 1.5C and several aspects of the Paris Agreement”.

Rogelj was a coordinating lead author on chapter two of the IPCC and is a for working group one on the IPCC’s forthcoming .

He tells Carbon Brief that there are at least two potential interpretations of the Paris ambition to “pursue efforts towards 1.5C”. One is that of limiting peak warming to 1.5C and the other is overshooting this level before returning below 1.5C, Rogelj says: “Planning to simply miss it is not a reasonable interpretation for a scenario that wants to be fully aligned with the Paris Agreement.”

He also points to of the deal, which commits to reaching a “balance” between human sources and sinks of all greenhouse gases. This goal is likely to require net-negative CO2, for which the SDS provides no detailed pathway.

Negative CO2 emissions could be provided via , such as (BECCS), or using “”, such as afforestation.

The IEA says that negative emissions do indeed offer one way that the SDS could become aligned to a 1.5C limit. A cumulative total of around 300bn tonnes of CO2 (GtCO2) would need to be removed to bridge this gap, it adds. There are over the sustainability and deliverability of such extensive deployment, however, and these are acknowledged by the IEA.

The WEO says:

“[I]t would be possible in the light of concern about [negative emissions technologies] to construct a scenario that goes further than the Sustainable Development Scenario and delivers a 50% chance of limiting warming to 1.5C without any reliance on net-negative emissions on the basis of a zero carbon world by 2050.”

[Other groups have developed a limited of that already do this, which are included in the IPCC’s and the figure above.]

To go beyond its SDS, the IEA says the world would need to tackle “hard to abate” sectors, such as aviation, heavy industry and heat for buildings. This would include near-universal building retrofits and the development and retrofitting of new technologies for industrial processes.

The IEA says this “would not amount to a simple extension” of the changes in the SDS, instead “pos[ing] challenges that would be very difficult and very expensive to surmount.” It adds that tackling some of these areas would require social acceptance and behavioural change:

“This is not something that is within the power of the energy sector alone to deliver. It would be a task for society as a whole…Change on a massive scale would be necessary across a very broad front, and would impinge directly on the lives of almost everyone.”

If the IEA were to develop a 1.5C scenario, despite the challenges it would present, then the agency’s modelling could be used by policymakers to inform their energy and climate choices. Such guidance would be pertinent as governments reconsider their climate pledges under the Paris Agreement, with a fresh round of “” due in 2020.

Coal changes

The outlook includes various changes since last year’s edition, reflecting shifts in the base year – there was growth in demand in 2018 – and new or amended policy.

As a result, the IEA has once again revised down its outlook for coal demand in the central STEPS pathway, as the chart below shows (red line). However, it has also raised its near-term outlook for coal, in part due to China’s renewed industries to prop up flagging growth.

Historical global coal demand (black line, millions of tonnes of oil equivalent) and the IEA’s previous central scenarios for future growth (shades of blue). This year’s STEPS is shown in red and the SDS is in yellow. Source: IEA and previous editions of the outlook. Chart by Carbon Brief using .

Despite the near-term increase in expected demand, this year’s outlook affirms that coal use would remain below the global peak reached in 2014, if stated plans and policies are met as per the STEPS. Nevertheless, this would leave coal demand significantly above the level in its SDS, where warming is limited to well-below 2C (yellow line, above).

According to the STEPS, rising is one of the key factors holding global coal use steady, despite rapid falls in developed economies, such as the US and EU.

Part of the reason for this increase in India is a large expected buildout of new coal-fired power stations, with 232GW of capacity built by 2040 in the STEPS, roughly doubling its and accounting for a third of global additions.

The IEA says India’s coal capacity growth could be cut “sharply”, if declines in the cost of battery storage are faster than expected. Solar and cheap storage could “reshape the evolution of India’s power mix”, the IEA says, offering a “very compelling economic and environmental proposition”.

It is also worth comparing the 232GW of new coal capacity expected by the IEA, with India’s current pipeline of , of which a quarter has been frozen in construction for years.

Another 510GW of new coal has been cancelled since 2010 due to competition from cheaper renewables, financial distress at utility firms and public opposition.

In addition, the Indian government has electricity demand growth, meaning existing coal capacity is running less than two-thirds of the time. Moreover, data for 2019 to date suggests India’s electricity .

The Indian government recently a highly ambitious target for solar, wind and biomass capacity to reach 450GW, potentially as soon as 2030, when the IEA STEPS outlook sees just 344GW having been added. If this target is met, then wind, solar and other low-carbon sources could largely meet rising demand without new coal, according to recent .

※ 全文及圖片詳見:()

作者

如果有一件事是重要的,如果能為孩子實現一個願望,那就是人類與大自然和諧共存。

於特有生物研究保育中心服務,小鳥和棲地是主要的研究對象。是龜毛的讀者,認為龜毛是探索世界的美德。

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

【其他文章推薦】

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

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

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

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

※別再煩惱如何寫文案,掌握八大原則!