網路資訊

據北京市科委消息，截至2015年年底，北京共建成公用充電樁5008根，2016年將再建5000根。 日前，"電動社區"行動計畫暨北京市充電設施公共服務管理平臺（e充網）啟動，將選擇500家社區率先實現電源條件到車位，並在無充電樁安裝條件社區率先投放500台移動充電車。 北京市"電動社區"行動計畫對於三類情況不同的社區給出了三種解決方案：對於有固定停車位元且具備電容量的社區，遴選500家，率先實現電源條件到車位；對於無固定停車位的社區，鼓勵在公共管理區域率先建設公用充電樁；在無充電樁安裝條件的社區，將投放500台移動充電車，方便車主預約充電車到車位充電，其投放範圍覆蓋北京16區中包括老舊社區、保障房社區、大型居住社區等各類社區200個。 公用充電樁將實現手機支付 據e充網工作人員表示，目前e充網已經實現了北京地區建設運營商全納入，全市所有公用充電樁的位置與導航資訊均收入到了APP之中。 此外，在充電樁國標符合性改造的過程中，統一支付結算（支持支付寶、微信、銀聯）、即時資料更新、充電樁預約等功能也會同步實施，即充電樁升級一批，其即時資料、統一支付結算等功能便實現一批，到今年6月底，電動汽車車主可以從"多卡不通用"的困境中解放出來，用手機實現線上查詢支付等諸多功能。 e充網工作人員介紹，目前北京已有604根快充樁（直流樁）實現了統一支付結算、即時資料更新的功能。 本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理 【其他文章推薦】 ※帶您來了解什麼是  USB CONNECTOR   ? ※自行創業 缺乏曝光? 下一步" 網站設計 "幫您第一時間規劃公司的門面形象 ※如何讓商品強力曝光呢? 網頁設計公司 幫您建置最吸引人的網站，提高曝光率!! ※綠能、環保無空污,成為 電動車 最新代名詞，目前市場使用率逐漸普及化 ※廣告預算用在刀口上， 網站設計公司 幫您達到更多曝光效益 Orignal From: 北京公用充電樁數量今年將破萬 實現手機支付

中汽協日前預測，2016年全國電動汽車和插電式混合動力車的銷量預計將超過70萬輛，較2015年的銷量增長一倍。 2015年電動車和插電式混合動力車的合併銷量為331092輛，較2014年增長了340%。其中包括247482輛電動車和83610輛插電式混合動力車，在24萬輛多的電動汽車銷量中，包括146719輛乘用車，另有100763輛為商用車。插電式混合動力車的銷量中，60663輛為乘用車，22947輛為商用車。 根據2015年起草的藍圖，政府計畫到2020年在全國範圍內新建12000個充電站和480枚充電樁。2014年年底，全國共有780個充電站共31000枚充電樁。2015年政府還為27個省市自治區設定了電動車的最低銷量目標。 政府預計，這些措施到位後，自主品牌車企的電動車和插電式混合動力車銷量到2020年可達100萬輛，到2025年可達300萬輛。 本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理 【其他文章推薦】 ※為什麼 USB CONNECTOR 是電子產業重要的元件? ※ 網頁設計 一頭霧水??該從何著手呢? 找到專業技術的 網頁設計公司 ，幫您輕鬆架站! ※想要讓你的商品成為最夯、最多人討論的話題? 網頁設計公司 讓你強力曝光 ※想知道最厲害的 台北網頁設計公司推薦 、 台中網頁設計公司推薦 專業設計師"嚨底家"!! Orignal From: 2016年電動車和插電式混合動力車銷量預計將超過70萬輛

國際車商BMW推出的電動車i3是目前市面上體型最小的電動車款之一，續航力相對也較差。據傳，今年i3將進行部份改版，讓續航力從目前的81英哩（129公里）延長48%到120英哩（192公里）。 《自由時報》指出 ，BMW的市場及銷售主任Ian Robertson在接受媒體採訪時，表示i3今年將有小改版的計畫。但除了續航力之外，並未說明外型與其他設計是否會有更動。 i3 電動版目前最高時速為150公里，0至100公里加速時間為7.2秒，屬於性能較佳的房車。此外，i3有純電版與油箱版，當電池耗盡後可用9公升的油箱開車到充電樁地點。 （照片來源：BWM 官網） 本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理 【其他文章推薦】 ※ USB CONNECTOR 掌控什麼技術要點? 帶您認識其相關發展及效能 ※評比前十大 台北網頁設計 、 台北網站設計 公司知名案例作品心得分享 ※智慧手機時代的來臨， RWD網頁設計 已成為網頁設計推薦首選 ※評比 南投搬家公司費用 收費行情懶人包大公開 Orignal From: BMW i3小改版 續航力增48%

北極震盪下，中國、台灣面臨數十年難得一見的低溫，連深圳與台北的平地都下起冰霰。這樣的天氣暴露出電動車的一大缺點──由於鋰電池在低溫環境下放電量不穩，因此電動車的續航力也大受挑戰。 根據美國AAA Automotive Research Center所做的研究，同一輛電動車在攝氏24度左右的溫度下可行駛約168公里，但在攝氏-6.7度左右時，行駛距離大幅縮減到只剩約69公里。而美國能源部及環保署的資料也載示，同樣在攝氏-6.7度的環境下，汽油車續航力會下降12%，但電動車會降低34%。 EnergyTrend鋰電池/電動車研究指出，同樣的問題也會發生在手機、平板等攜帶裝置上，主要的原因是鋰電池長時間處於寒冷環境下時，因化學反應不正常，會使放電電流變少，導致可用容量降低。若是攜帶式裝置，可將裝置帶在身上「保暖」，但電動車可不能如法炮製。 電動車近兩年來展望長紅，不只有Tesla、Faraday Future等新公司出現，保時捷、BMW、Audi、Nissan、Toyota、Ford、福斯汽車等國際車廠也紛紛推出電動車款，且銷售量持續攀升。尤其在霾害嚴重的中國，已正式將電動車列為重點發展項目。但在氣候的限制下，如何解決鋰電池的續航力降低問題，就成為一大議題。 從材料面、系統面解決 EnergyTrend調研團隊指出，中國雖然大力推動電動車，但仍以華中以南地區為推行主力，原因正在於東北、華北等地氣候太過嚴寒，不利於鋰電池與電動車行駛，不只電池容量會降低，汽車也會有無法發動的問題。 要解決此一問題，主要分成材料改良與系統改良。在材料方面，可改用更耐嚴寒氣候的電池材料；在系統方面，則又分成耐低溫零件以及低溫系統的使用。分析師指出，目前已有廠商針對電動車耐寒的議題提出相關技術。 以台灣電動機車Gogoro為例，Gogoro設計有高溫預防模式與低溫保護模式，在低溫狀況下，低溫保護模式啟用並使動力輸出降低，但騎乘一段時間後電池溫度就能慢慢回到正常。 目前相關技術仍在發展當中，但隨著電動車市場擴大，這將成為不得不跨越的一大難題。 （照片來源：Wikepedia） 本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我...

一、登錄認證基於過濾器鏈 Spring Security的登錄驗證流程核心就是過濾器鏈。當一個請求到達時按照過濾器鏈的順序依次進行處理，通過所有過濾器鏈的驗證，就可以訪問API接口了。 SpringSecurity提供了多種登錄認證的方式，由多種Filter過濾器來實現，比如： BasicAuthenticationFilter實現的是HttpBasic模式的登錄認證 UsernamePasswordAuthenticationFilter實現用戶名密碼的登錄認證 RememberMeAuthenticationFilter實現登錄認證的"記住我"的功能 SmsCodeAuthenticationFilter實現短信驗證碼登錄認證 SocialAuthenticationFilter實現社交媒體方式登錄認證的處理 Oauth2AuthenticationProcessingFilter和Oauth2ClientAuthenticationProcessingFilter實現Oauth2的鑒權方式 根據我們不同的需求實現及配置，不同的Filter會被加載到應用中。 二、結合源碼講解登錄驗證流程 我們就以用戶名、密碼登錄方式為例講解一下Spring Security的登錄認證流程。 2.1 UsernamePasswordAuthenticationFilter 該過濾器封裝用戶基本信息（用戶名、密碼），定義登錄表單數據接收相關的信息。如： 默認的表單用戶名密碼input框name是username、password 默認的處理登錄請求路徑是/login、使用POST方法 2.2 AbstractAuthenticationProcessingFilter的doFilter方法的驗證過程 UsernamePasswordAuthenticationFilter繼承自抽象類AbstractAuthenticationProcessingFilter，該抽象類定義了驗證成功與驗證失敗的處理方法。 2.3 驗證成功之後的Handler和驗證失敗之後的handler 也就是說當我們需要自定義驗證成功或失敗的處理方法時，要去實現Aut...

.NET Core具有一個承載（Hosting）系統，承載需要在後台長時間運行的服務，一個ASP.NET Core應用僅僅是該系統承載的一種服務而已。承載系統總是採用依賴注入的方式來消費它在服務承載過程所需的服務。對於承載系統來說，原始的服務註冊總是體現為一個 IServiceCollection 集合，最終的依賴注入容器則體現為一個 IServiceProvider 對象，如果要將第三方依賴注入框架整合進來，就需要利用它們解決從IServiceCollection集合到IServiceProvider對象之間的適配問題。 一、IServiceCollection =>ContainerBuilder=>IServiceProvider 具體來說，我們可以在IServiceCollection集合和IServiceProvider對象之間設置一個針對某個第三方依賴注入框架的 ContainerBuilder 對象。我們先利用包含原始服務註冊的IServiceCollection集合來創建一個ContainerBuilder對象，再利用該對象來構建作為依賴注入容器的IServiceProvider對象。 二、 IServiceProviderFactory<TContainerBuilder> 如上圖所示的兩種轉換是利用一個 IServiceProviderFactory<TContainerBuilder> 對象完成的。如下面的代碼片段所示，IServiceProviderFactory<TContainerBuilder>接口定義了兩個方法，其中 CreateBuilder 方法利用指定的IServiceCollection集合創建出對應的ContainerBuilder對象，而 CreateServiceProvider 方法則進一步利用這個ContainerBuilder對象創建出作為依賴注入容器的IServiceProvider對象。 public interface IServiceProviderFactory<TContainerBuilder> { TContainerBuilder CreateBuilder(IServiceCollection ...

.NET Core前後端分離快速開發框架(Core.3.0+AntdVue) 目錄 引言 時間真快，轉眼今年又要過去了。回想今年，依次開源發布了 Colder.Fx.Net.AdminLTE(254Star) 、 Colder.Fx.Core.AdminLTE(335Star) 、 DotNettySocket(82Star) 、 IdHelper(47Star) ，這些框架及組件都是本着以實際出發，實事求是的態度，力求提高開發效率（我自己都是第一個使用者），目前來看反響不錯。但是隨着前端和後端技術的不斷變革，尤其是前端，目前大環境已經是前後端完全分離為主的開發模式，在這樣的大環境和必然趨勢之下，傳統的MVC就顯得有些落伍了。在這樣的背景下，一款前後端分離的.NET開發框架就顯得尤為必要，由此便定了框架的升級目標： 前後端分離 。 首先後端技術的選擇，從目前的數據來看，.NET Core的發展遠遠快於.NET Framework，最簡單的分析就是Colder.Fx.Core.AdminLTE發布比Colder.Fx.Net.AdminLTE晚，但是星星卻後來居上而且比前者多30%，並且這個差距在不斷擴大，由點及面的分析可以看出我們廣大.NET開發人員學習的熱情和积極向上的態度，並不是某些人所認為的那麼不堪（ 走自己的路，讓別人說去吧 ）。大環境上微軟积極擁抱開源，大力發展.NET Core， 可以說前途一片光明。因此後端決定採用 .NET Core3.0 ，不再浪費精力去支持.NET Framework。 然後是前端技術選擇，首選是三大js框架選擇，也是從實際出發，Vue相對其它而言更加容易上手，並且功能也毫不遜色，深得各種大小公司喜歡，如果偏要說缺點的話，那就是對TS支持不行，但是即將發布Vue3.0肯定會改變這一缺陷。選擇了Vue之後，然後就是UI框架的選擇了，這裏的選擇更多了，我選擇了Ant Design Vue，理由便是簡潔方便，十分符合我的設計理念。 技術選型完畢之後便...

什麼是RootMessageId？ 為了理解RootMessageId先簡單介紹一下CAT的數據結構設計。CAT客戶端會將所有消息都封裝為一個完整的消息樹（MessageTree），消息樹可能包括Transaction、Event、Heartbeat、Metric等類型的消息。具體如下： Transaction：適合記錄跨越系統邊界的程序訪問行為,比如遠程調用，數據庫調用，也適合執行時間較長的業務邏輯監控，Transaction用來記錄一段代碼的執行時間和次數 Event：用來記錄一件事發生的次數，比如記錄系統異常，它和transaction相比缺少了時間的統計，開銷比transaction要小 Heartbeat：表示程序內定期產生的統計信息, 如CPU利用率, 內存利用率, 連接池狀態, 系統負載等 Metric：用於記錄業務指標、指標可能包含對一個指標記錄次數、記錄平均值、記錄總和，業務指標最低統計粒度為1分鐘 歡迎關注微信公眾號： 萬貓學社 ，每周一分享Java技術乾貨。 其中，Transaction類型的消息可作為消息樹節點，而其他消息只可作為消息樹的恭弘=叶 恭弘子節點，也就是Transaction是一個可嵌套的遞歸結構。比如： 消息樹的每一節點都有一個屬性messageId，用來唯一表示節點本身，其構成為：{domain}-{ip}-{timestamp}-{自增index}。另外還有兩個屬性，分別是parentMessageId, rootMessageId。parentMessageId表示父節點的messageId； rootMessageId 則表示整個消息樹的根節點的messageId。這兩個屬性在之後CAT的調用鏈分析與分佈式調用鏈分析中發揮了關鍵作用。 歡迎關注微信公眾號： 萬貓學社 ，每周一分享Java技術乾貨。 為什麼在日誌中記錄？ 根據RootMessageId可以追蹤某一個請求的整個分佈式調用鏈，結合每一條日誌快速定位耗費性能的癥結，做針對性的性能優化。更加方便地做性能優化，特別是TP95、TP99等指標。 遇到偶爾發生的bug，是最讓人頭疼的，只有先從日誌中找線索，但是在海量的日誌中找到出現bug的那一個請求是很困難的。有了上游API提供的RootMessage...

本文微信公眾號「AndroidTraveler」首發。 背景 在開發過程中，調試是必不可少的一項工作。 當我們要確定項目的邏輯時，當我們要了解界面的生命周期時，當我們發現新寫的邏輯與期望效果不一致時，當我們覺得數據有問題時...... 而調試有兩種方式： 第一種就是使用 debug 模式運行 APP，然後通過斷點讓程序運行到指定位置進行分析。 第二種就是打日誌的方式，通過觀察輸出來確定程序是否運行到該位置以及此時的數據。 本篇文章主要聚焦在第二種方式上面。 在 Android 裏面，打日誌使用的系統 API 是 Log，你以為直接使用就完了嗎？ 封裝 假設你在需要打印日誌的地方直接使用系統的 API，那麼當遇到下面情況時，會「牽一發而動全身」。 場景一：如果我打印日誌要用三方庫的日誌 API，那麼我要查找項目所有使用位置，並一一替換。 場景二：如果我希望在開發環境下打印日誌，release 環境不打印，這個時候每個位置都需要單獨做處理。 因此我們需要在使用 Log 進行日誌打印之前，做一層封裝。 假設我們的類名字為 ZLog，代碼如下： import android.util.Log; /** * Created on 2019-10-26 * * @author Zengyu.Zhan */ public class ZLog { public static int v(String tag, String msg) { return Log.v(tag, msg); } public static int d(String tag, String msg) { return Log.d(tag, msg); } public static int i(String tag, String msg) { return Log.i(tag, msg); } public static int w(String tag, String msg) { return Log.w(tag, msg); } public sta...

前言 近兩年，Java 版本升級頻繁，感覺剛剛掌握 Java8，寫本文時，已聽到 java14 的消息，無論是嘗鮮新特性()，還是由於項目升級/兼容需要，我們可能都要面臨管理多個 Java 版本的情 另外 Oracle 自 Java11 開始，更改了用戶協議，任何商用都會收費。在寫本文時，得到消息「微軟宣布加入 OpenJDK」，打不過就選擇 OpenJDK。隨便 G 一下，當個故事了解就可以 配置單個 Java 環境變量本身沒什麼技術含量可言，但當需要管理多個 Java 版本，重複配置環境變量顯然是非常枯燥的，按照傳統的配置方式我們又不能靈活的切換 Java 版本 那要如何輕鬆管理與使用多個版本 Java？ 多版本 Java 管理 顯然我們不是第一個有這種困境的人，我所知道的現有方案有三種: 本文主要說明如何通過 sdkman 打破我們面臨的困境，幫助我們靈活配置與使用 Java sdkman 介紹 SDKMAN 是一個用於在大多數基於 Unix 系統上管理 多個軟件開發工具包 (Java, Groovy, Scala, Kotlin and Ceylon. Ant, Gradle 等) 的并行版本的工具 。 它提供了一個方便的命令行接口 (CLI) 和 API，用於 安裝 、 切換 、 刪除 和 列出候選對象 。本文主要通過管理 Java 來說明 sdkman 的使用 sdkman 安裝 在類 unix 平台上安裝 sdkman 非常容易。它可以順利的安裝在Mac OSX、Linux、WLS、Cygwin、Solaris和FreeBSD 上，同時還支持Bash和 ZSH shell。 只需打開一個新終端機並輸入: $ curl -s "https://get.sdkman.io" | bash 按照相應的指令提示，完成相應的操作後繼續輸入: $ source "$HOME/.sdkman/bin/sdkman-init.sh" 到這裏我們就可以驗證 sdk 的安裝版本了: $ sdk version 上圖紅色框標記显示我當前 sdkman 的版本，每次執行 sdk version 命令時，都會檢查是否會有...

人生苦短，我選Python 前文傳送門 讀取 Excel 不知道各位同學有沒有見過有關 Python 操作 Excel 的廣告。小編是見過好多次的，還只需 ￥9.9 就能學習，今天小編就為大家帶來免費的 Python 操作 Excel 的入門教程。 仔細看，仔細學，本文價值 ￥9.9 哦~~~ 這牛逼吹得我自己都有點臉紅。 既然要操作 Excel ，那我們就需要先建立一個 Excel 。 首先在 Excel 中創建 3 個 Sheet ，別跟我說不知道什麼是 Sheet ，可能你不適合看本篇內容。 測試使用 Excel 已經上傳至代碼倉庫，有需要的同學可以取用。 Excel 內容如下： 請先暫時忽略右下角的日期時間，這日期時間並無實際作用，僅用來演示使用。 這是一個 Sheet 的數據，同樣的 Sheet 存在 3 個。 可能各位同學看到這個 Excel 以後大致能猜到小編要幹啥了，對，沒錯，你猜對了，小編就是要算一下平均成績。 那麼用 Excel 自帶的公式來算平均成績不香么，非要用 Python 算，勞民傷財的。 Excel 自帶的函數確實強大，這個不得不服，但是，我如果要跨 Sheet 的操作呢？本文要玩的騷操作就是要跨 Sheet 計算平均成績。 首先，我們需要導入第三方模塊 xlrd ，因為是第三方的模塊，沒有安裝的同學需要先安裝。在命令行中輸入： pip install xlrd 等待進度條走完就好了。 獲取 workbook： 首先，我們需要在代碼中打開我們剛才創建的 Excel : workbook = xlrd.open_workbook('test.xlsx') 小編這裏為了方便，將 test.xlsx 和代碼放在同一目錄，實際在操作中需注意文件的路徑問題，不管是使用相對路徑還是絕對路徑，都要寫對。 Sheet 有關操作： 有關 Sheet 的操作有很多，我們列舉幾個常用的： # 輸出所有 sheet 的名字 print(workbook.sheet_names()) # 獲取所有的 sheet print...

1. WPF有，而UWP沒有的圖片平鋪功能 在WPF中只要將ImageSource的 TileMode 屬性設置為 Tile 即可實現圖片的平鋪，具體可見WPF的這些文檔： WPF圖片平鋪功能我幾乎沒用過，只是作為基礎中的基礎知識記住了用法。我以為那麼基礎的功能在UWP肯定有，根本不用懷疑，所以當我在UWP中發現這麼基礎的東西居然沒有時真的嚇了一跳。 上圖左面是WPF版本的 TileBrush ,右邊是UWP版本，可以看到UWP版本功能少了一大半。 這麼小的一個類，我覺得沒必要在這裏做簡化吧。幸好圖片平鋪可以使用Win2D里的實現。 2. UWP中的圖片平鋪功能 <Grid> <Rectangle x:Name="Background" /> </Grid> 假設有以上的XAML，要在名為 Background 的元素上應用合成畫筆，首先引用 nuget包，然後參考官方文檔中 的部分使用圖片創建一個合成畫筆： var compositor = ElementCompositionPreview.GetElementVisual(this).Compositor; var imageBrush = compositor.CreateSurfaceBrush(); var loadedSurface = LoadedImageSurface.StartLoadFromUri(new Uri("ms-appx:///110Strawberry.png")); imageBrush.Surface = loadedSurface; imageBrush.Stretch = CompositionStretch.None; 現在就差創建一個 SpriteVisual 並把它應用到Background的VisualTree上了，順便一提，是這張圖片： 不過要實現平鋪功能還需要創建一個BorderEffect： var borderEffect = new BorderEffect { Source = new CompositionEffectSourceParameter("source...

目       錄 1.      概述... 1 2.      登陸信息... 2 3.      設備驅動... 3 4.      組態建模... 3 5.      手機APP. 5 6.      視頻演示... 6 1.   概述 此次我們團隊人員對iNeuOS進行了全面升級，主要升級內容包括： （1）    設備容器增加設備驅動，包括：西門子（S7-200smart、S7-300、S7-400、S7-1200、S7-1500）、三菱（FxSerial）、MQTT協議等。 （2）    組態建模可以設置背景，作為開發大屏展示使用，背景可以為一個獨立的圖元信息。 （3）    組態建模可以按瀏覽器大小按比例縮放，以適應移動APP显示。 （4）    組態建模標題框和文本框可以設置背景和字體顏色。 （5）    組態建模文本框綁定數據點后，可以設置上下限值，以用於判斷，進行顏色報警显示。 （6）    組態建模文本框可以設置數據保留小數點位數。 （7）    組態建模可以自定義畫任意圖形，並且填充顏色等。 （8）    組態建模開發好的視圖，可以右鍵單擊數值文本框，查看數據曲線趨勢。 （9）    手機移動APP，組態建模開發的視圖，直接可以显示在手機APP上。 （10）進行其他優化。 2.   演示信息 在線演示：  （注：服務器比較慢，請耐心等待。用戶自已註冊用戶，體驗系統功能） 視頻演示： 驅動開發...

Java 8 新特性系列文章索引。 前言 我們都知道 Lambda 和 Stream 是 Java 8 的兩大亮點功能，在前面的文章里已經介紹過 Lambda 相關知識，這次介紹下 Java 8 的 Stream 流操作。它完全不同於 java.io 包的 Input/Output Stream ，也不是大數據實時處理的 Stream 流。這個 Stream 流操作是 Java 8 對集合操作功能的增強，專註於對集合的各種高效、便利、優雅的 聚合操作 。藉助於 Lambda 表達式，顯著的提高 編程效率 和 可讀性 。且 Stream 提供了 并行計算 模式，可以簡潔的編寫出并行代碼，能充分發揮如今計算機的多核處理優勢。 在使用 Stream 流操作之前你應該先了解 Lambda 相關知識，如果還不了解，可以參考之前文章： 。 1. Stream 流介紹 Stream 不同於其他集合框架，它也不是某種數據結構，也不會保存數據，但是它負責相關計算，使用起來更像一個高級的迭代器。在之前的迭代器中，我們只能先遍歷然後在執行業務操作，而現在只需要指定執行什麼操作， Stream 就會隱式的遍歷然後做出想要的操作。另外 Stream 和迭代器一樣的只能單向處理，如同奔騰長江之水一去而不復返。 由於 Stream 流提供了 惰性計算 和 并行處理 的能力，在使用并行計算方式時數據會被自動分解成多段然後并行處理，最後將結果匯總。所以 Stream 操作可以讓程序運行變得更加高效。 2. Stream 流概念 Stream 流的使用總是按照一定的步驟進行，可以抽象出下面的使用流程。 數據源（source） -> 數據處理/轉換（intermedia） -> 結果處理（terminal ） 2.1. 數據源 數據源（source） 也就是數據的來源，可以通過多種方式獲得 Stream 數據源，下面列舉幾種常見的獲取方式。 Collection.stream(); 從集合獲取流。 Collection.parallelStream(); 從集合獲取 并行流。 Arrays.stream(T array) or Stream.of(); 從數組獲取流。 Buffered...