 |
-- 會員 / 註冊 --
|
 |
|
|
|
Java編程方法論：響應式Spring Reactor 3設計與實現 ( 簡體 字) |
| 作者：知秋 | 類別：1. -> 程式設計 -> JAVA -> Spring |
| 譯者： |
| 出版社：電子工業出版社 |  3dWoo書號： 53356
詢問書籍請說出此書號！【缺書】
NT售價： 445 元 |
| 出版日：9/1/2020 |
| 頁數：348 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787121394768 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：推薦序一
Towards a More Exciting, More Reactive Tomorrow
Hi, Spring fans! It’s an interesting time to be alive. Today, the possible applications any programmer can build today are much more numerous than they were when I first started. The opportunities are so much more than they were before. It’s possible to write code that runs on the server-side, on the backend, in giant systems, in big data platforms, in streaming platforms, on mobile phones, in cars, in the browser, on your watch, on your tablets, on your TVs, etc., all while using fairly similar languages, and while using similar skills. All of these destinations are also open and - often - open-source. It costs almost nothing to build this stuff. It takes time and it takes a computer with an internet connection. But, the tools are free. This is an ideal scenario. We can do almost anything today. I am very excited to see the opportunities expand in the last 20 years.
You know what I did not expect to happen so quickly? For the possibilities to become so good. I did not expect them to become so refined, so polished in so short a period of time. I was excited when Java ME came out. Now we have Android and iOS. I was excited when Hadoop came out. Now we have Spark and TensorFlow. I was excited when JDBC, the Servlet specification and Struts came out. Now we have Spring. I was excited when Netscape introduced JavaScript. Now we have Vue.js and React and Angular. I was excited when Spring came out. Now we have Spring Boot. I was excited when C++ came out. Now we have Kotlin. I was excited when Ant came out. Now we have Maven and Gradle. I was excited when the ideas around continuous delivery started to crystalize. Now we have a Gitops-centric culture powered by technologies like Kubernetes. Everything has gotten so much better in the last 20 years. All of these things were exciting to me when they first arrived. But they’re better now. They’re easier. They’re faster. They’re cheaper. They’re a natural evolution of the ideas we’ve known for a long time.
I feel the same enthusiasm — excitement — when I look at reactive code. I love Spring. I know that it’s one of the most powerful ways to express my microservices. Today, I am excited about the opportunity to use Spring and Reactor to build much more resource-efficient, easier-to-understand, reactive services.
Reactive Programming is a natural next step in the creation of cloud native applications. Reactive libraries offer me several tentpole benefits.
I’ll expand on those points here:
Reactive Programming offers one abstraction, no matter what the application (server-sent events, RSocket, WS, HTTP, Kafka, etc). A unified abstraction greatly simplifies the integration and composition of disparate services and data.
Reactive Programming supports more declarative, concise, deterministic ways to express complex, multithreaded algorithms. Remember: only one person TRULY understands how to write safe, concise multithreaded Java code... and it’s NOT you! (It is not me, either!) I don’t know who it is. It’s better to let the library and framework do the dangerous work of managing concurrency.
Reactive Programming supports services that are more robust. Reactive libraries give us an API protocol to signal that our consumer is overwhelmed, or that it can not handle anymore. Libraries like Project Reactor provide operators to consistently handle errors, back-pressure, and more. The result is safer code with much fewer lines of code.
I believe that all new projects should embrace Reactive Programming, if possible.
So, when I saw that there is a book being written in Chinese to help people understand how to write reactive applications, I was very excited! I hope you’ll take the opportunity to read this book, dear reader, and to learn how to work with Reactor and to see how it supports you when building reactive applications with Spring. The opportunities we have today are endless. We have the tools to build almost anything, easily, and to ship that software into production for very cheap. And I am excited to see what you will build with these tools.
Josh?Long
Spring?官方布道師
Java?Champion?成員
Kotlin?GDE?谷歌官方認證開發專家
San?Francisco,?USA
July?2020
推薦序二
Dear Reader,
Welcome on your journey to building more efficient and resilient applications, welcome to Reactive Programming!
On this path, you will challenge yourself and you will be rewarded with a new mindset that will help you create your next distributed Java services. Interacting with remote services is a common task performed by distributed systems and those interactions take time outside of the calling application control. Multiple reasons are behind this time fluctuation: network latency, the nature of the task run or even a system interruption. At the end of the day, if the calling code needs a result back it will be negatively impacted by that same time because it needs to actively wait for it.
Enter Reactive Programming which gives you the great power of bending space-time to your will! Or sort of... It gives you the ability to remove the negative impact of waiting for anything, so your Thread or CPU is not pinned and can perform other tasks.
Since you can’t control how long a remote call will last, you will need to "schedule" the activities your application needs to perform "when" those remote services produce a result. For instance, if your application talks to a remote REST endpoint, it will eventually produce an HTTP response.
"Non Blocking" applications will provide a listener reacting only "when" an underlying network event signals the response back to you. What will do the calling Thread then? It will be able to return to the server worker pool or preparing a next HTTP call, thus increasing service concurrent capacity. It’s a scalable design some runtimes have adopted for years, you can implement it with a single thread like Node.JS!
"Non-Blocking" is foundational to Reactive Programming but what does "Reactive" mean anyway? It’s maybe not the first time you read the word "Reactive", it has various meanings and it’s even mistaken for the popular UI library ReactJS. In this book, when "Reactive" is mentioned, it will always refer to the "reactive-streams" specification which is a clear documented definition adopted by major libraries. "Reactive Streams" defines how an arbitrary "producer" can interact with one or more "consumers" in a Reactive way. Once implemented, the contract offers two key qualities designed to help developers build 100% non-blocking applications: Error Isolation and Flow Control. The former quality contributes to a greater resiliency and availability, producers errors must not interrupt the application, and instead they will forward errors to registered listeners. The latter quality means that producers can’t produce more data than consumers are able to consume at any given time. This rule is also known as "backpressure" and it is designed to avoid "unbounded buffers" which has resources consequences on the application host. It helps that one of the major adopters of "Reactive Streams" is the Spring Reactive stack itself including Spring WebFlux and Project Reactor. They do a great job at hiding away a lot of the technical details from the specification I’ve briefly mentioned in this intro. They provide rich APIs to build reactive flows and help you focus on the "what" and not the "how".
In fact, there are various elements in these libraries designed to ease your first experience with Reactive Programming. First and foremost, Spring can become as much reactive as you need: You can start developing on top of a well-known programming model, Spring MVC, running on Tomcat and you can selectively introduce the modern reactive "WebClient" coming with Spring WebFlux. You can also start returning Project Reactor reactive types Flux and Mono in your Spring MVC controllers the same way you can return CompletableFuture. Ultimately you can just swap your container and start running on top of Netty or Tomcat reactive bridge. Spring conventions such as annotations also matter and most Java developers have learned them for sometimes many years! For instance, @RestController works in both Spring MVC and WebFlux as one could expect. Learning Reactive Programming with Spring is intended to feel like you are learning at home, in a familiar setup.
In this book, you will work with the Spring Reactive stack. I highly recommend you pair this learning opportunity with a good use case that could benefit from going Reactive. For instance, an application depending on a remote service, or an application on the edge of your system serving as a port of entry for many concurrent users.
Learning a new mindset is never easy but it is highly rewarding. Many of the lessons Reactive programming offers apply to all modern software engineering. I think the greatest of these lessons is that it always pays off to be ready with a plan when a component outside your control does not work as you expect.
Good luck!
Stephane?Maldini
Netflix?高級軟件工程師
Spring?Reactor?項目創始人
Reactor-Netty?項目負責人
Spring?Framework?項目貢獻者
推薦序三
與本書作者的初識是在2016年，我那會兒因為連載一些關于Spring Boot和Spring Cloud的入門內容，所以組建了一些交流群，于是跟他便有了交集。而我對他的進一步了解，是在我讀了他寫的名為“Spring框架中的設計模式”系列博文后，他對框架原理的研究、理解與表述都非常優秀，并且這個系列的文章得到了諸多讀者的高度評價！所以我也在我的博客中轉載了這個系列的文章，希望更多的Spring愛好者能夠讀到。
與作者相識多年，雖說互相交流的時間與次數并不算多，但他一直以來對技術研究的熱情與對技術分享的堅持，是最讓我敬佩的。我本不是一個B站用戶，但正是因為他在B站上分享了國外頂級課程與前沿技術，才讓我這個老古董也用上了B站！如果你跟我一樣，熱愛前沿技術，追逐先進理念，那么就跟著他的步伐吧，一定可以打開思路并有所收獲！
言歸正傳，說說作者的“Java編程方法論系列叢書”。如果你是一名Java開發者，那么你是否聽說過響應式編程？如果有，那么有沒有將其應用到日常開發中？我曾經在幾個開發交流群中問過這兩個問題，得到的答案大多是：知道但沒怎么用過。
這樣的狀況非常容易理解，每一種新技術、新理念都需要時間去沉淀與積累，因為有非常多的工作都建立在既有技術框架之上，大象翻身并不是那么容易的事。新技術與新理念，不會快速地被大規模鋪開應用。但不得不說，這個系列圖書為我們帶來的內容正是Java生態在逐步擁抱的編程方法。所以，還有什么理由不去了解和學習呢？
我強烈推薦作者的這個系列圖書，因為它們不僅可以幫我們認識到響應式編程的本質原理，同時也兼顧了我們常用的Spring、Netty、WebFlux等框架內容，可以很好地幫助我們將理論與實戰聯系起來，便于理解與學習。對于這種在國外已經非常流行，而在國內還處于萌芽狀態的編程理念，如果你也跟我們一樣認可這個方向，何不跟隨著作者，一起學習它、使用它，為你信仰的技術布道，讓身邊的技術人都能為之收益？豈不快哉？
翟永超
《Spring Cloud微服務實戰》作者
推薦序四
有幸與本書作者相識多年，他嚴謹的治學態度和認真的工作作風都讓我佩服不已。
作者是國內響應式編程的布道者，這本新書是他的第二本大作，千呼萬喚始出來，令人激動萬分。
作者是一個非常樂于分享知識和為別人解答困惑的人。這本關于響應式Reactor的著作是他反復校對并認真打磨的精華之作。寫書殊為不易，分享精神更是難能可貴，他能把自己積累的Reactor技術經驗總結成Java編程方法論并出版成書是一件非常了不起的事情。因此，當我得知他要將自己對Java編程和響應式編程的技術經驗編寫成書的時候，甚是欣喜。因為我相信這本書不僅會讓讀者對響應式編程等核心知識有深入理解和技術成長，同時也會讓讀者對Java編程方法論有自我思考。
響應式編程是未來架構的一次升級。如果你有幸閱讀過作者的第一本書《Java編程方法論：響應式RxJava與代碼設計實戰》，那么這本書非常適合作為你的進階讀物。在Java社區中，RxJava和RxJava 2非常流行，而另一個新的響應式編程庫就是Reactor。Reactor是完全基于響應式規范設計和實現的庫，在使用上直觀、易懂，而且Reactor也是Spring 5中響應式編程的基礎。因此，學習和掌握Reactor可以讓我們更好地在Spring 5中使用WebFlux。
對于我們而言，響應式編程是思維方式的升級，也是一次充滿更多可能性的機會。隨著響應式編程技術的成熟，如果能把全異步流式能力引入業務開發中，不僅可以幫助項目提升性能，還可以給項目帶來更多的靈活性。不論是剛接觸響應式編程的入門讀者，還是已經有響應式編程實戰經驗的進階讀者，閱讀這本書都會收獲頗多。
梁桂釗
《高可用可伸縮微服務架構》聯合作者
公眾號“服務端思維”作者
推薦序五
自從Java第一框架Spring Framework 5.0（2016年6月發布了第一個里程碑版本）內置響應式組件（spring-webflux）開始，響應式編程逐步進入了廣大程序員的視野。響應式編程經常被理解成并發編程或者高性能編程，因為它們看起來很相似，以至于很多人無法分清這些概念，但是實際上設計原則完全不同，這不可避免地給人帶來了一些困惑。人們常把響應式編程和函數式響應式編程（FRP）混為一談。一些人覺得響應式編程換湯不換藥，他們早就在這么寫代碼了，但其實并不一樣。在Java企業級應用開發領域，也有一些關于響應式編程的探索，雖然取得了一些不錯的成果，但也暴露出很多容易犯的錯誤。
響應式編程是從命令式編程到聲明式異步編程的重大轉變，是企業級應用架構的一次重大升級。要想正確地編寫出優質、高效的響應式代碼，需要在編程思想上發生重大的轉變，就如同20年前從面向過程編程到面向對象編程的轉變一樣。
知秋在響應式編程方面的認知及落地能力，得到了國內業界人士的廣泛認可，他出品的教學視頻也得到了國外專家們的肯定及推廣，他是國內名副其實的響應式編程和NIO領域的專家。這本書的出現可謂是及時雨，對有相關學習、工作需求的小伙伴來說，是很好的指導。但要注意的是，該“Java編程方法論系列叢書”不是泛泛的API講解，也不是快速入門指南，更不是玄而又玄的概念堆疊，而是成體系的、傳授編程思想和技巧的響應式編程學習圖書。如果你內心不夠強大，那么這本書或許不適合你，因為閱讀它并不輕松，但當你堅持閱讀數小時并收獲知識時，幸運的你將在技術上得到成長。
總有那么幾本書，它們會影響我們的思維習慣，甚至改變我們看待這個世界的方式。我真心地希望能早幾年看到這本書，因為我確信它會給讀者帶來很有意義的影響。
于文龍
國藥控股上海生物醫藥有限公司 架構師
推薦序六
隨著Project Reactor 3（后來的Spring Reactor 3）在Spring Framework 5.2中正式登場，響應式編程“殺入”了國內應用開發的前線。不少開發團隊為了能夠實現低延遲和高吞吐量而選擇使用Spring WebFlux。但這并非易事，全新的編程風格和設計方式讓很多程序員望而卻步。相信國內不少對響應式編程有一些認識和了解的人都看過本書作者分享的內容，他被視為國內少有的響應式編程和NIO方面的專家，多年來一直堅持對JDK、Reactor、Reactor-Netty、Spring WebFlux和RxJava等技術進行源碼解讀和知識分享。時至今日，Spring全家桶和Project Reactor的子項目依舊保持著活躍的更新頻率，作者也一直保持著對這些項目的代碼設計和源碼更新的關注。為了幫助國人更快地接受響應式編程思想，近兩年他分享了大量相關前沿技術、源碼解讀和設計思路的視頻和文章，并將這些內容發布到B站（https://space.bilibili.com/2494318）和simtoco（https://www.simtoco.com）上，供需要的人觀看和學習，這些視頻無疑是國內響應式編程領域的寶貴財富。與此同時，“Java編程方法論系列叢書”的第二本書伴隨著這個過程，歷經反復迭代，終于出版了！
以往，由于Java程序中存在著過多或過重的線程及I/O阻塞，因此系統性能浪費情況嚴重。如果將它們替換為完全異步的處理方式，就能夠讓機器發揮出更優秀的性能，減少不必要的浪費。當下，Spring的相關項目都在向響應式編程的方向發展，由Spring所提供的Reactor為Java程序員帶來了更高性能的編程實現方式。但想要駕馭Reactor并不容易，如果你對Reactor理解得不夠，錯誤的使用方式將會導致你的響應式程序的性能不及傳統的命令式程序，因此對Reactor的認識和理解非常重要。限于篇幅，這本書無法將Spring Reactor的一切都一一展現出來，作者在網絡上更新發布的相關分享視頻同樣值得學習。圖書較為系統，而視頻則更加靈活，可以看作這本書的補充和拓展。
響應式編程基礎庫Reactor在Java編程中正變得無處不在，就像Netty被用在眾多涉及網絡通信的開源項目中一樣，Reactor也必將出現在更多流行的開源項目中，諸如Reactor-Netty和Spring WebFlux，而這些項目必將成為網絡通信、IoT及Web等應用領域中的新主流。能夠越早地對Reactor的設計思想與實現方式有所認識和了解，你在未來的工作和學習中將越早地把握住自己的未來。
尹相宇
simviso成員
推薦序七
響應式編程的概念最早是在20世紀90年代末提出的，其讓微軟的Erik Mejier從中獲取了靈感，設計、開發了.NET的Rx庫（2012年開源），這也是響應式編程最初的實現。在此之后，Reactive Streams出現了。最開始，它是由NetFlix、Pivotal（現為Vmware Tanzu）及LightBend等幾家公司的開發人員提出的。緊接著，在2015年，JDK正式將Reactive Streams作為標準納入，其就是我們熟知的JDK 9中的Flow API。這也從側面證明了響應式編程是多么優秀，連JDK都將其收入麾下。
隨著近些年響應式編程理念的興起，越來越多的廠商逐步將其投入使用。NetFlix和Spring是其中的佼佼者。為了進行響應式改造，Spring將Project Reactor納入旗下進行孵化，而Project Reactor后來成了我們熟知的Spring Reactor。在Web方面，正如Josh Long所說的，隨著并發量不斷增加及微服務架構流行，傳統的Spring MVC漸漸無法滿足我們的需求，這也讓我們感受到了傳統I/O的局限性。雖然我們可以通過增加線程來提高性能，但這并不是最佳解決方案。線程對于我們來說可能是廉價的，但是對于JVM之類的平臺來說，則是一種很寶貴的資源。因此，基于Spring Reactor的Spring WebFlux也就應運而生了。正如Spring官方文檔所講的那樣，響應式編程雖然不能讓程序跑得更快，但它所具備的這種異步、非阻塞的特性能夠讓程序以較少的固定數量線程和較少的內存來處理更多的業務。這樣能夠充分利用機器資源，從而避免了我們以往為了提高性能而不停地增加機器的尷尬局面。
響應式編程是未來的趨勢，對于Java開發人員而言，它的到來無疑使整個Java生態體系得到了一次升華，并且改變了我們以往的思維方式及開發方式，也改變了眾多開發人員以往對Java的看法。可以說，響應式編程給Java帶來了第二春。
目前，響應式編程在國內才剛剛開始，知秋所編寫的“Java編程方法論系列叢書”無疑填補了國內這個領域的空白。如果你對響應式編程了解不多，可以先閱讀這本書的前作《Java編程方法論：響應式RxJava與代碼設計實戰》。為了能讓讀者更好地入門并掌握響應式編程，知秋在B站和simtoco上錄制并上傳了大量相關源碼解讀視頻，感興趣的小伙伴可以關注B站上的simviso官方頁面，以及simtoco官網。在閱讀這本書時，建議你一定要反復閱讀，注意細節。如果你的Java基礎不是很牢固，那么切記不要隨意跳讀，你可以跟隨配套解讀視頻進行學習，這樣能降低學習難度。
最后，我相信響應式編程必將在未來大放光彩。
劉嘉誠（花名 虛生花）
simviso成員
前言
最近幾年，隨著Go、Node等新語言、新技術的出現，Java作為服務器端開發語言老大的地位受到了不小的挑戰。雖然Java的市場地位在短時間內并不會發生改變，但Java社區還是將挑戰視為機遇，并努力、不斷地提高自身應對高并發服務器端開發場景的能力。
為了應對高并發服務器端開發場景，在2009年，微軟提出了一個更優雅地實現異步編程的方式——Reactive Programming，我們稱之為響應式編程。隨后，各語言很快跟進，都擁有了屬于自己的響應式編程實現。比如，JavaScript語言就在ES6中通過Promise機制引入了類似的異步編程方式。同時，Java社區也在快速發展，Netflix和LightBend公司提供了RxJava和Akka Stream等技術，使得Java平臺也有了能夠實現響應式編程的框架。
當下，我們通過Mina和Netty這樣的NIO框架其實就能完成高并發下的服務器端開發任務，但這樣的技術只掌握在少數高級開發人員手中，因為它們難度較大，并不適合大部分普通開發者。
雖然目前已經有不少公司在實踐響應式編程，但整體來說，其應用范圍依舊不大。出現這種情況的原因在于當下缺少簡單、易用的技術，這些技術需要能使響應式編程更加普及，并做到如同Spring MVC一樣結合Spring提供的服務對各種技術進行整合。
在2017年9月28日，Spring 5正式發布。Spring 5發布最大的意義在于，它將響應式編程技術的普及向前推進了一大步。而同時，作為在背后支持Spring 5響應式編程的框架Spring Reactor，也進入了里程碑式的3.1.0版本。
在本書中，我會帶著大家學習響應式編程，并通過逐層遞進的方式對Spring Reactor的源碼設計與實現進行解讀，以揭示其中的設計精髓，幫助大家靈活運用及提升代碼設計思維。
限于篇幅，本書不可能涉及Spring Reactor的所有知識點。作為本書的有效補充，我特意錄制了一套針對Spring Reactor源碼進行全面解讀的配套視頻。未來，我也會根據Spring Reactor版本的更新迭代，適時地推出新的解讀視頻，幫助大家走在響應式技術發展的最前沿。
最后，感謝Spring官方布道師Josh Long和Spring Reactor項目創始人Stephane Maldini在百忙之中為本書作序。作為響應式編程研究人員，受到官方認可，深感榮幸！另外，也要感謝家人及simviso小伙伴的一路支持。
|
內容簡介：本書主要專注于解讀Spring Reactor 3的代碼設計與實現。全書共10章，其中第1、2章將從接口的設計入手，逐漸深入介紹Reactor中Flux源與訂閱者Subscriber的諸多交互實現細節；第3章將通過對調度器的研究來向讀者展示其中的優秀設計，可以幫助讀者更好地掌握Java并發庫，同時可以使讀者對使用Reactor進行異步編程有更好的認識；第4章將接觸到一些常用的Reactor操作，方便讀者寫出可重用度高、邏輯清晰的代碼；第5、6、7章將著重分析Reactor中Processor的設計實現，不僅講述了它的使用場景，還講解了其中的內在原理，以及如何應對未來項目開發過程中可能遇到的種種問題；第8章將介紹并分析Reactor特別提供的Context，這是Reactor為了應對生產-訂閱模式下的響應式編程在異步環境中對訂閱關系上下文進行管理所產生的問題而給出的解決方案，Spring Framework 5.2中的響應式事務也是基于它實現的；第9章將主要介紹Reactor中的測試，同時帶著讀者一步一步設計實現一個針對Reactor項目的測試庫；第10章將主要介紹Reactor中的調試，可以教會讀者根據不同的需求采取不同的調試方式。本書適合有Java編程基礎的中高級Java開發工程師、想要學習代碼設計思路與技巧的讀者、對響應式編程感興趣的讀者閱讀。 |
目錄：第1章 響應式編程概述 1
1.1 并發與并行的關系 1
1.2 如何理解響應式編程中的背壓 2
1.3 源碼接口設計啟示 3
1.4 如何看待眾多函數表達式 11
1.5 Reactor與RxJava的對比 12
1.6 小結 14
第2章 對Flux的探索 15
2.1 對Flux.subscribe訂閱邏輯的解讀 16
2.1.1 對CoreSubscriber的解讀 17
2.1.2 對LambdaSubscriber的解讀 22
2.1.3 AtomicXxxFieldUpdater的技法應用 24
2.2 用Flux.create創建源 30
2.2.1 FluxCreate細節探索 31
2.2.2 Flux的快速包裝方法 36
2.2.3 Reactor 3中的generate方法 38
2.3 蛇行走位的QueueSubscription 43
2.3.1 無界隊列SpscLinkedArrayQueue 44
2.3.2 QueueSubscription.requestFusion的催化效應 47
2.4 Mono的二三事 50
2.5 通過BaseSubscriber自定義訂閱者 51
2.6 將常見的監聽器改造成響應式結構 53
2.7 Flux.push的特殊使用場景及細節探索 56
2.8 對Flux.handle的解讀 58
2.9 小結 63
第3章 調度器 64
3.1 深入理解Schedulers.elastic 65
3.1.1 CachedScheduler的啟示 66
3.1.2 ElasticScheduler的類定義思路 68
3.1.3 對Schedulers.decorateExecutorService的解讀 69
3.1.4 對ElasticScheduler.schedule的解讀 70
3.1.5 對ElasticScheduler.DirectScheduleTask的解讀 71
3.1.6 對Schedulers.directSchedule的解讀 73
3.1.7 對ElasticScheduler.ElasticWorker的解讀 74
3.1.8 ElasticScheduler小結 82
3.2 深入解讀publishOn 82
3.2.1 publishOn流程概述 82
3.2.2 對FluxPublishOn的解讀 85
3.3 深入解讀subscribeOn 98
3.4 Flux.parallel＆Flowable.parallel的并行玩法 108
3.5 ParallelFlux.runOn＆ParallelFlowable.runOn的調度實現 117
3.6 小結 122
第4章 對Reactor操作的解讀 123
4.1 filter操作 123
4.2 transform操作 124
4.3 compose與transformDeferred操作 127
4.4 批處理操作 129
4.4.1 buffer操作 130
4.4.2 window 操作 132
4.4.3 groupBy 操作 139
4.5 merge和mergeSequential操作 140
4.6 flatMap和flatMapSequential操作 142
4.7 concatMap操作 144
4.8 combineLatest操作 145
4.9 ConnectableFlux的二三事及對reactor-bug的分析 146
4.10 小結 158
第5章 對Processor的探索 159
5.1 UnicastProcessor詳解 160
5.2 DirectProcessor詳解 164
5.3 EmitterProcessor詳解 169
5.4 ReplayProcessor詳解 174
5.5 小結 188
第6章 TopicProcessor及Reactor中匹配Disruptor的實現代碼 189
6.1 初識TopicProcessor 190
6.2 TopicProcessor構造器 195
6.3 對RingBuffer中publish方法的解讀 205
6.4 對MultiProducerRingBuffer的解讀 208
6.4.1 RingBuffer中的UnsafeSupport 210
6.4.2 RingBuffer中的next與publish操作 216
6.5 TopicProcessor.onSubscribe及類BossEventLoopGroup的設計 221
6.6 TopicProcessor.subscribe及類WorkerEventLoopGroup的設計 225
6.7 小結 241
第7章 對WorkQueueProcessor的解讀 242
7.1 WorkQueueProcessor的requestTask 244
7.2 WorkQueueProcessor的subscribe 247
7.3 冷熱數據源的區別 251
7.4 實例詳解 252
7.5 小結 255
第8章 Reactor中**的Context 256
8.1 Context的設計緣由 256
8.2 對Context的解讀 258
8.3 小結 265
第9章 Reactor中的測試 267
9.1 StepVerifier測試源碼解析 267
9.1.1 接口定義 267
9.1.2 接口實現 269
9.1.3 驗證 274
9.2 StepVerifier測試應用 275
9.3 操作時間測試 278
9.4 使用StepVerifier進行后置驗證 286
9.5 關于Context的測試 289
9.6 使用TestPublisher對自定義中間操作進行測試 296
9.7 使用PublisherProbe檢查執行路徑 305
9.8 小結 310
**0章 Reactor中的調試 311
10.1 啟用調試模式 311
10.2 在調試模式下讀取堆棧跟蹤信息 315
10.3 通過checkpoint方式進行調試 325
10.4 記錄訂閱關系下與操作流程相關的日志 326
10.5 小結 326 |
| 序： |
|
