项目织机
為什么為什么？
Java 8流背后的驅(qū)動程序之一是并發(fā)編程。 在流管道中，指定要完成的工作，然后任務(wù)將自動分發(fā)到可用處理器上：
var result = myData.parallelStream().map(someBusyOperation).reduce(someAssociativeBinOp).orElse(someDefault);當(dāng)數(shù)據(jù)結(jié)構(gòu)便宜且可拆分為多個部分且操作使處理器繁忙時，并行流將發(fā)揮出色的作用。 這就是它的設(shè)計目的。
但是，如果您的工作負(fù)載包含大部分阻塞的任務(wù)，那么這對您沒有幫助。 那是您的典型Web應(yīng)用程序，可以處理許多請求，每個請求都花費大量時間等待REST服務(wù)，數(shù)據(jù)庫查詢等結(jié)果。
1998年，令人驚奇的是，Sun Java Web Server（Tomcat的前身）在單獨的線程而不是OS進(jìn)程中運行了每個請求。 這樣就可以滿足數(shù)千個并發(fā)請求！ 如今，這并不令人驚訝。 每個線程占用大量內(nèi)存，典型服務(wù)器上不能擁有數(shù)百萬個線程。
這就是為什么服務(wù)器端編程的現(xiàn)代口號是：“永不阻塞！” 相反，您指定一旦數(shù)據(jù)可用就應(yīng)該發(fā)生什么。
這種異步編程風(fēng)格非常適合服務(wù)器，使它們可以輕松支持?jǐn)?shù)百萬個并發(fā)請求。 對于程序員來說不是那么好。
這是使用HttpClient API的異步請求：
HttpClient.newBuilder().build().sendAsync(request, HttpResponse.BodyHandlers.ofString()).thenAccept(response -> . . .);.thenApply(. . .);.exceptionally(. . .);我們通常用語句實現(xiàn)的功能現(xiàn)在被編碼為方法調(diào)用。 如果我們喜歡這種編程風(fēng)格，就不會在Lisp中使用我們的編程語言來編寫語句和編寫快樂的代碼。
諸如JavaScript和Kotlin之類的語言為我們提供了“異步”方法，在這些方法中，我們編寫語句，然后將這些語句轉(zhuǎn)換為您剛剛看到的方法調(diào)用。 很好，只不過它意味著現(xiàn)在有兩種方法-常規(guī)方法和轉(zhuǎn)換方法。 而且您不能混合使用它們（“紅色藥丸/藍(lán)色藥丸”的分界）。
Project Loom從Erlang和Go等語言中獲得指導(dǎo)，在這些語言中，阻塞并不是什么大問題。 您可以在“光纖”或“輕型線程”或“虛擬線程”中運行任務(wù)。 該名稱尚待討論，但我更喜歡“光纖”，因為它很好地表示了多個光纖在一個載波線程中執(zhí)行的事實。 當(dāng)發(fā)生阻塞操作（例如等待鎖定或I / O）時，光纖將停放。 停車比較便宜。 如果很多時候都停放了一根承載線，則可以支撐一千根光纖。
請記住，Project Loom不能解決所有并發(fā)問題。 如果您有大量計算任務(wù)并且想讓所有處理器內(nèi)核都忙，它對您無濟(jì)于事。 它對于使用單個線程的用戶界面沒有幫助（用于序列化對不是線程安全的數(shù)據(jù)結(jié)構(gòu)的訪問）。 在該用例中繼續(xù)使用AsyncTask / SwingWorker / JavaFX Task 。 當(dāng)您有很多任務(wù)花費大量時間阻塞時，Project Loom很有用。
注意 如果您已經(jīng)存在很長時間了，您可能還記得早期的Java版本具有映射到OS線程的“綠色線程”。 但是，有一個關(guān)鍵的區(qū)別。 當(dāng)綠色線程被阻塞時，其承載線程也被阻塞，從而阻止了同一承載線程上的所有其他綠色線程取得進(jìn)展。
踢輪胎
在這一點上，Project Loom仍處于探索階段。 API會不斷變化，因此在假期過后嘗試使用該代碼時，請準(zhǔn)備好適應(yīng)最新的API版本。
您可以從http://jdk.java.net/loom/下載Project Loom的二進(jìn)制文件，但是它們很少更新。 但是，在Linux機(jī)器或VM上，自己構(gòu)建最新版本很容易：
git clone https://github.com/openjdk/loom cd loom git checkout fibers sh configure make images根據(jù)您已經(jīng)安裝的內(nèi)容， configure可能會失敗一些，但是消息會告訴您需要安裝哪些軟件包才能繼續(xù)進(jìn)行。
在API的當(dāng)前版本中，光纖或現(xiàn)在稱為虛擬線程的虛擬線程表示為Thread類的對象。 這是三種生產(chǎn)纖維的方法。 首先，有一個新的工廠方法可以構(gòu)造OS線程或虛擬線程：
Thread thread = Thread.newThread(taskname, Thread.VIRTUAL, runnable);如果您需要更多自定義，則有一個構(gòu)建器API：
Thread thread = Thread.builder().name(taskname).virtual().priority(Thread.MAX_PRIORITY).task(runnable).build();但是，一段時間以來，手動創(chuàng)建線程一直被認(rèn)為是較差的做法，因此您可能不應(yīng)該執(zhí)行任何一種操作。 而是將執(zhí)行程序與線程工廠一起使用：
ThreadFactory factory = Thread.builder().virtual().factory(); ExecutorService exec = Executors.newFixedThreadPool(NTASKS, factory);現(xiàn)在，熟悉的固定線程池將以與以往相同的方式從工廠調(diào)度虛擬線程。 當(dāng)然，還將有OS級別的載體線程來運行這些虛擬線程，但這是虛擬線程實現(xiàn)的內(nèi)部。
固定線程池將限制并發(fā)虛擬線程的總數(shù)。 默認(rèn)情況下，從虛擬線程到載體線程的映射是通過使用系統(tǒng)屬性jdk.defaultScheduler.parallelism或默認(rèn)情況下Runtime.getRuntime().availableProcessors()所給定數(shù)量的內(nèi)核的jdk.defaultScheduler.parallelism池完成的。 您可以在線程工廠中提供自己的調(diào)度程序：
factory = Thread.builder().virtual().scheduler(myExecutor).factory();我不知道這是否是人們想要做的。 為什么載具線程多于核心？
返回我們的執(zhí)行人服務(wù)。 您可以在虛擬線程上執(zhí)行任務(wù)，就像在OS級線程上執(zhí)行任務(wù)時一樣：
for (int i = 1; i <= NTASKS; i++) {String taskname = "task-" + i;exec.submit(() -> run(taskname)); } exec.shutdown(); exec.awaitTermination(delay, TimeUnit.MILLISECONDS);作為一個簡單的測試，我們可以在每個任務(wù)中入睡。
public static int DELAY = 10_000;public static void run(Object obj) {try {Thread.sleep((int) (DELAY * Math.random()));} catch (InterruptedException ex) {ex.printStackTrace();}System.out.println(obj);}如果現(xiàn)在將NTASKS設(shè)置為1_000_000并在工廠生成器中.virtual() ，則該程序?qū)⑹?#xff0c;并顯示內(nèi)存不足錯誤。 一百萬個OS級線程占用大量內(nèi)存。 但是使用虛擬線程，它可以工作。
至少，它應(yīng)該可以工作，并且對我之前的Loom版本確實有效。 不幸的是，在12月5日下載的構(gòu)建中，我得到了一個核心轉(zhuǎn)儲。 當(dāng)我嘗試使用Loom時，這時有發(fā)生。 希望它會在您嘗試時解決。
現(xiàn)在，您可以嘗試更復(fù)雜的事情了。 亨氏·卡布茲（Heinz Kabutz）最近為益智游戲提供了一個程序，該程序可加載數(shù)千個Dilbert卡通圖像。 對于每個日歷日，都有一個頁面，例如https://dilbert.com/strip/2011-06-05 。 程序讀取這些頁面，在每個頁面中找到卡通圖像的URL，然后加載每個圖像。 這是一堆亂七八糟的期貨 ，有點像：
CompletableFuture.completedFuture(getUrlForDate(date)).thenComposeAsync(this::readPage, executor).thenApply(this::getImageUrl).thenComposeAsync(this::readPage).thenAccept(this::process);使用光纖，代碼更加清晰：
exec.submit(() -> { String page = new String(readPage(getUrlForDate(date)));byte[] image = readPage(getImageUrl(page));process(image); });當(dāng)然，每個對readPage的調(diào)用readPage塊，但是對于纖維，我們不在乎。
嘗試一下您關(guān)心的事情。 閱讀大量網(wǎng)頁，進(jìn)行處理，進(jìn)行更多的阻塞讀取，并享受光纖阻塞便宜的事實。
結(jié)構(gòu)化的一致性
Project Loom的最初動機(jī)是實現(xiàn)光纖，但今年早些時候，該項目開始了針對結(jié)構(gòu)化并發(fā)的實驗性API。 在這篇強(qiáng)烈推薦的文章 （從中拍攝以下圖像）中，Nathaniel Smith提出了結(jié)構(gòu)化的并發(fā)形式。 這是他的中心論點。 在新線程中啟動任務(wù)實際上并不比使用GOTO編程好，即有害：
new Thread(runnable).start();當(dāng)多個線程在沒有協(xié)調(diào)的情況下運行時，這將是意大利面條代碼。 在1960年代，結(jié)構(gòu)化編程將goto替換為分支，循環(huán)和函數(shù)：
現(xiàn)在，結(jié)構(gòu)化并發(fā)的時機(jī)已經(jīng)到來。 啟動并發(fā)任務(wù)時，通過閱讀程序文本，我們應(yīng)該知道它們何時全部完成。
這樣，我們可以控制任務(wù)使用的資源。
到2019年夏季，Project Loom有了一個用于表達(dá)結(jié)構(gòu)化并發(fā)的API。 不幸的是，由于最近進(jìn)行了統(tǒng)一線程和光纖API的實驗，該API目前處于混亂狀態(tài)，但是您可以通過http://jdk.java.net/loom/上的原型進(jìn)行嘗試。
在這里，我們安排了許多任務(wù)：
FiberScope scope = FiberScope.open(); for (int i = 0; i < NTASKS; i++) {scope.schedule(() -> run(i)); } scope.close();調(diào)用scope.close()阻塞，直到所有光纖完成。 請記住，光纖阻塞不是問題。 一旦關(guān)閉示波器，您就可以確定光纖已經(jīng)完成。
FiberScope是可FiberScope的，因此您可以使用try -with-resources語句：
try (var scope = FiberScope.open()) {... }但是，如果其中一項任務(wù)永遠(yuǎn)無法完成怎么辦？
您可以使用截止日期（ Instant ）或超時（ Duration ）創(chuàng)建范圍：
try (var scope = FiberScope.open(Instant.now().plusSeconds(30))) {for (...)scope.schedule(...); }截止期限/超時之前尚未完成的所有光纖都將被取消。 怎么樣？ 繼續(xù)閱讀。
消除
取消一直是Java的痛苦。 按照慣例，您可以通過中斷線程來取消線程。 如果線程正在阻塞，則阻塞操作以InterruptedException終止。 否則，設(shè)置中斷狀態(tài)標(biāo)志。 正確地進(jìn)行檢查是乏味的。 可以重置中斷狀態(tài)，或者InterruptedException是已檢查的異常，這沒有幫助。
java.util.concurrent中取消的處理一直不一致。 考慮ExecutorService.invokeAny 。 如果有任務(wù)產(chǎn)生結(jié)果，則其他任務(wù)將被取消。 但是CompletableFuture.anyOf允許所有任務(wù)運行完成，即使其結(jié)果將被忽略。
2019年夏季的Project Loom API解決了取消問題。 在該版本中，光纖具有cancel操作，類似于interrupt ，但是取消是不可撤銷的。 如果當(dāng)前光纖已被取消，則靜態(tài)Fiber.cancelled方法將返回true 。
當(dāng)示波器超時時，其光纖將被取消。
取消可以由FiberScope構(gòu)造函數(shù)中的以下選項控制。
- CANCEL_AT_CLOSE ：關(guān)閉范圍取消所有計劃的光纖而不是阻塞
- PROPAGATE_CANCEL ：如果取消擁有光纖，則任何新調(diào)度的光纖都會自動取消
- IGNORE_CANCEL ：無法取消預(yù)定的光纖
所有這些選項都未在頂層設(shè)置。 PROPAGATE_CANCEL和IGNORE_CANCEL選項是從父范圍繼承的。
如您所見，有相當(dāng)多的可調(diào)整性。 我們必須看看重新考慮此問題后會發(fā)生什么。 對于結(jié)構(gòu)化并發(fā)，當(dāng)示波器超時或被強(qiáng)制關(guān)閉時，必須自動取消示波器中的所有光纖。
螺紋局部
讓我感到驚訝的是，Project Loom實現(xiàn)者的痛苦之一是ThreadLocal變量，以及更深奧的東西-上下文類加載器AccessControlContext 。 我不知道有那么多東西騎在線程上。
如果您的數(shù)據(jù)結(jié)構(gòu)不適合并發(fā)訪問，則有時可以在每個線程中使用一個實例。 經(jīng)典示例是SimpleDateFormat 。 當(dāng)然，您可以繼續(xù)構(gòu)造新的格式化程序?qū)ο?#xff0c;但這并不高效。 所以你想分享一個。 但是全球
public static final SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");將無法正常工作。 如果兩個線程同時訪問它，則格式可能會混亂。
因此，每個線程中有一個是有意義的：
public static final ThreadLocal<SimpleDateFormat> dateFormat= ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));要訪問實際的格式化程序，請致電
String dateStamp = dateFormat.get().format(new Date());首次調(diào)用get時，將調(diào)用構(gòu)造函數(shù)中的lambda。 從那時起，get方法返回屬于當(dāng)前線程的實例。
對于線程，這是公認(rèn)的做法。 但是，如果真的有一百萬個光纖，您是否真的想擁有一百萬個實例？
這對我來說不是問題，因為使用線程安全的東西（如java.time格式化程序）似乎更容易。 但是Project Loom一直在考慮“范圍本地”對象-那些FiberScope被重新激活了。
在線程與處理器數(shù)量一樣多的情況下，線程局部變量也已被用作處理器局部性的近似值。 可以實際模擬用戶意圖的API可以支持此功能。
項目狀況
想要使用Project Loom的開發(fā)人員自然會沉迷于API，如您所見，該API尚未解決。 但是，許多實施工作都處于幕后。
一個關(guān)鍵部分是在操作阻塞時使光纖停放。 已經(jīng)完成了網(wǎng)絡(luò)連接，因此您可以在光纖內(nèi)連接到網(wǎng)站，數(shù)據(jù)庫等。 當(dāng)前不支持本地文件操作塊時的停車。
實際上，在JDK 11、12和13中已經(jīng)重新實現(xiàn)了這些庫，這是對頻繁發(fā)布實用程序的致敬。
目前尚不支持在監(jiān)視器上進(jìn)行阻塞（ synchronized塊和方法），但最終需要這樣做。 ReentrantLock現(xiàn)在可以了。
如果光纖以本機(jī)方法阻塞，則將“固定”線程，并且所有光纖都不會前進(jìn)。 Project Loom對此無能為力。
Method.invoke需要更多工作才能得到支持。
有關(guān)調(diào)試和監(jiān)視支持的工作正在進(jìn)行中。
如前所述，穩(wěn)定性仍然是一個問題。
最重要的是，性能還有一段路要走。 停放光纖不是免費的午餐。 每次都需要替換運行時堆棧的一部分。
在所有這些方面都取得了很大的進(jìn)展，所以讓我們回顧一下開發(fā)人員關(guān)心的API。 現(xiàn)在是查看Project Loom并考慮如何使用它的好時機(jī)。
同一類代表線和纖維對您有價值嗎？ 還是您希望將某些Thread行李丟掉？ 您是否認(rèn)同結(jié)構(gòu)化并發(fā)的承諾？
試一下Project Loom，看看它如何與您的應(yīng)用程序和框架一起工作，并為無畏的開發(fā)團(tuán)隊提供反饋！
翻譯自: https://www.javacodegeeks.com/2019/12/project-loom.html
總結(jié)
- 上一篇： 安保备案登记表怎么填（安保备案登记）
- 下一篇： 摇篮配置