開發核心源碼解析

Ⅰ 「SpringCloud原理」Ribbon核心組件以及運行原理萬字源碼剖析

大家好，本文我將繼續來剖析SpringCloud中負載均衡組件Ribbon的源碼。本來我是打算接著OpenFeign動態代理生成文章直接講Feign是如何整合Ribbon的，但是文章寫了一半發現，如果不把Ribbon好好講清楚，那麼有些Ribbon的細節理解起來就很困難，所以我還是打算單獨寫一篇文章來剖析Ribbon的源碼，這樣在講Feign整合Ribbon的時候，我就不再贅述這些細節了。好了，話不多說，直接進入主題。

這是個很簡單的東西，就是服務實例數據的封裝，裡面封裝了服務實例的ip和埠之類的，一個服務有很多台機器，那就有很多個Server對象。

ServerList是個介面，泛型是Server，提供了兩個方法，都是獲取服務實例列表的，這兩個方法其實在很多實現類中實現是一樣的，沒什麼區別。這個介面很重要，因為這個介面就是Ribbon獲取服務數據的來源介面，Ribbon進行負載均衡的服務列表就是通過這個介面來的，那麼可以想一想是不是只要實現這個介面就可以給Ribbon提供服務數據了？事實的確如此，在SpringCloud中，eureka、nacos等注冊中心都實現了這個介面，都將注冊中心的服務實例數據提供給Ribbon，供Ribbon來進行負載均衡。

通過名字也可以知道，是用來更新服務注冊表的數據，他有唯一的實現，就是PollingServerListUpdater，這個類有一個核心的方法，就是start，我們來看一下start的實現。

通過這段方法我們可以看出，首先通過isActive.compareAndSet(false, true)來保證這個方法只會被調用一下，然後封裝了一個Runnable，這個Runnable幹了一件核心的事，就是調用傳入的updateAction的doUpdate方法，然後將Runnable扔到了帶定時調度功能的線程池，經過initialDelayMs（默認1s）時間後，會調用一次，之後都是每隔refreshIntervalMs（默認30s）調用一次Runnable的run方法，也就是調用updateAction的doUpdate方法。

所以這個類的核心作用就是每隔30s會調用一次傳入的updateAction的doUpdate方法的實現，記住這個結論。

IRule是負責負載均衡的演算法的，也就是真正實現負載均衡獲取一個服務實例就是這個介面的實現。比如說實現類RandomRule，就是從一堆服務實例中隨機選取一個服務實例。

就是一個配置介面，有個默認的實現DefaultClientConfigImpl，通過這個可以獲取到一些配置Ribbon的一些配置。

這個介面的作用，對外主要提供了獲取服務實例列表和選擇服務實例的功能。雖然對外主要提供獲取服務的功能，但是在實現的時候，主要是用來協調上面提到的各個核心組件的，使得他們能夠協調工作，從而實現對外提供獲取服務實例的功能。

這個介面的實現有好幾個實現類，但是我講兩個比較重要的。

BaseLoadBalancer

核心屬性

allServerList：緩存了所有的服務實例數據

upServerList：緩存了能夠使用的服務實例數據。

rule：負載均衡演算法組件，默認是RoundRobinRule

核心方法

setRule：這個方法是設置負載均衡演算法的，並將當前這個ILoadBalancer對象設置給IRule，從這可以得出一個結論，IRule進行負載均衡的服務實例列表是通過ILoadBalancer獲取的，也就是 IRule 和 ILoadBalancer相互引用。setRule(rule)一般是在構造對象的時候會調用。

chooseServer：就是選擇一個服務實例，是委派給IRule的choose方法來實現服務實例的選擇。

BaseLoadBalancer這個實現類總體來說，已經實現了ILoadBalancer的功能的，所以這個已經基本滿足使用了。

說完BaseLoadBalancer這個實現類，接下來說一下DynamicServerListLoadBalancer實現類。DynamicServerListLoadBalancer繼承自BaseLoadBalancer，DynamicServerListLoadBalancer主要是對BaseLoadBalancer功能進行擴展。

DynamicServerListLoadBalancer

成員變數

serverListImpl：上面說過，通過這個介面獲取服務列表

filter:起到過濾的作用，一般不care

updateAction：是個匿名內部類，實現了doUpdate方法，會調用updateListOfServers方法

serverListUpdater：上面說到過，默認就是唯一的實現類PollingServerListUpdater，也就是每個30s就會調用傳入的updateAction的doUpdate方法。

這不是巧了么，serverListUpdater的start方法需要一個updateAction，剛剛好成員變數有個updateAction的匿名內部類的實現，所以serverListUpdater的start方法傳入的updateAction的實現其實就是這個匿名內部類。

那麼哪裡調用了serverListUpdater的start方法傳入了updateAction呢？是在構造的時候調用的，具體的調用鏈路是調用 restOfInit -> ()，這里就不貼源碼了

所以，其實DynamicServerListLoadBalancer在構造完成之後，默認每隔30s中，就會調用updateAction的匿名內部類的doUpdate方法，從而會調用updateListOfServers。所以我們來看一看 updateListOfServers 方法幹了什麼。

這個方法實現很簡單，就是通過調用 ServerList 的getUpdatedListOfServers獲取到一批服務實例數據，然後過濾一下，最後調用updateAllServerList方法，進入updateAllServerList方法。

其實很簡單，就是調用每個服務實例的setAlive方法，將isAliveFlag設置成true，然後調用setServersList。setServersList這個方法的主要作用是將服務實例更新到內部的緩存中，也就是上面提到的allServerList和upServerList，這里就不貼源碼了。

其實分析完updateListOfServers方法之後，再結合上面源碼的分析，我們可以清楚的得出一個結論，那就是默認每隔30s都會重新通過ServerList組件獲取到服務實例數據，然後更新到BaseLoadBalancer緩存中，IRule的負載均衡所需的服務實例數據，就是這個內部緩存。

從DynamicServerListLoadBalancer的命名也可以看出，他相對於父類BaseLoadBalancer而言，提供了動態更新內部服務實例列表的功能。

為了便於大家記憶，我畫一張圖來描述這些組件的關系以及是如何運作的。

說完一些核心的組件，以及他們跟ILoadBalancer的關系之後，接下來就來分析一下，ILoadBalancer是在ribbon中是如何使用的。

ILoadBalancer是一個可以獲取到服務實例數據的組件，那麼服務實例跟什麼有關，那麼肯定是跟請求有關，所以在Ribbon中有這么一個抽象類，，這個是用來執行請求的，我們來看一下這個類的構造。

通過上面可以看出，在構造的時候需要傳入一個ILoadBalancer。

中有一個方法executeWithLoadBalancer，這個是用來執行傳入的請求，以負載均衡的方式。

這個方法構建了一個LoadBalancerCommand，隨後調用了submit方法，傳入了一個匿名內部類，這個匿名內部類中有這么一行代碼很重要。

這行代碼是根據給定的一個Server重構了URI，這是什麼意思呢？舉個例子，在OpenFeign那一篇文章我說過，會根據服務名拼接出類似 http:// ServerA 的地址，那時是沒有伺服器的ip地址的，只有服務名，假設請求的地址是 http:// ServerA/api/sayHello ，那麼reconstructURIWithServer乾的一件事就是將ServerA服務名替換成真正的服務所在的機器的ip和埠，假設ServerA所在的一台機器（Server裡面封裝了某台機器的ip和埠）是192.168.1.101:8088，那麼重構後的地址就變成 http:// 192.168.1.101:8088/api/ sayHello ，這樣就能發送http請求到ServerA服務所對應的一台伺服器了。

之後根據新的地址，調用這個類中的execute方法來執行請求，execute方法是個抽象方法，也就是交給子類實現，子類就可以通過實現這個方法，來發送http請求，實現rpc調用。

那麼這台Server是從獲取的呢？其實猜猜也知道，肯定是通過ILoadBalancer獲取的，因為submit方法比較長，這里我直接貼出submit方法中核心的一部分代碼

就是通過selectServer來選擇一個Server的，selectServer我就不翻源碼了，其實最終還是調用ILoadBalancer的方法chooseServer方法來獲取一個服務，之後就會調用上面的說的匿名內部類的方法，重構URI，然後再交由子類的execut方法來實現發送http請求。

所以，通過對的executeWithLoadBalancer方法，我們可以知道，這個抽象類的主要作用就是通過負載均衡演算法，找到一個合適的Server，然後將你傳入的請求路徑 http:// ServerA/api/sayHello 重新構建成類似 http:// 192.168.1.101:8088/api/ sayHello 這樣，之後調用子類實現的execut方法，來發送http請求，就是這么簡單。

到這里其實Ribbon核心組件和執行原理我就已經說的差不多了，再來畫一張圖總結一下

說完了Ribbon的一些核心組件和執行原理之後，我們再來看一下在SpringCloud環境下，這些組件到底是用的哪些實現，畢竟有寫時介面，有的是抽象類。

Ribbon的自動裝配類：RibbonAutoConfiguration，我拎出了核心的源碼

RibbonAutoConfiguration配置類上有個@RibbonClients註解，接下來講解一下這個註解的作用

SpringClientFactory是不是感覺跟OpenFeign中的FeignContext很像，其實兩個的作用是一樣的，SpringClientFactory也繼承了NamedContextFactory，實現了配置隔離，同時也在構造方法中傳入了每個容器默認的配置類RibbonClientConfiguration。至於什麼是配置隔離，我在OpenFeign那篇文章說過，不清楚的小夥伴可以後台回復feign01即可獲得文章鏈接。

配置優先順序問題

優先順序最低的就是FeignContext和SpringClientFactory構造時傳入的配置類

至於優先順序怎麼來的，其實是在NamedContextFactory中createContext方法中構建時按照配置的優先順序一個一個傳進去的。

RibbonClientConfiguration提供的默認的bean

接下來我們看一下RibbonClientConfiguration都提供了哪些默認的bean

配置類對應的bean，這里設置了ConnectTimeout和ReadTimeout都是1s中。

IRule，默認是ZoneAvoidanceRule，這個Rule帶有過濾的功能，過濾哪些不可用的分區的服務（這個過濾可以不用care），過濾成功之後，繼續採用線性輪詢的方式從過濾結果中選擇一個出來。至於這個propertiesFactory，可以不用管，這個是默認讀配置文件的中的配置，一般不設置，後面看到都不用care。

至於為什麼容器選擇NacosServerList而不是ConfigurationBasedServerList，主要是因為這個配置類是通過@RibbonClients導入的，也就是比SpringClientFactory導入的RibbonClientConfiguration配置類優先順序高。

ServerListUpdater，就是我們剖析的PollingServerListUpdater，默認30s更新一次BaseLoadBalancer內部服務的緩存。

那麼在springcloud中，上圖就可以加上注冊中心。

三、總結

本文剖析了Ribbon這個負載均衡組件中的一些核心組件的源碼，並且將這些組件之間的關系一一描述清楚，同時也剖析了在發送請求的時候是如何通過ILoadBalancer獲取到一個服務實例，重構URI的過程。希望本篇文章能夠讓你知道Ribbon是如何工作的。

Ⅱ 如何開發自己的httpserver-nanohttpd源碼解讀

現在作為一個開發人員，http server相關的內容已經是無論如何都要了解的知識了。用curl發一個請求，配置一下apache，部署一個web server對我們來說都不是很難，但要想搞清楚這些背後都發生了什麼技術細節還真不是很簡單的。所以新的系列將是分享我學習Http Server的過程。

NanoHttpd是Github上的一個開源項目，號稱只用一個java文件就能創建一個http server，我將通過分析NanoHttpd的源碼解析如何開發自己的HttpServer。Github 地址：https://github.com/NanoHttpd/nanohttpd

在開始前首先簡單說明HttpServer的基本要素：
1.能接受HttpRequest並返回HttpResponse
2.滿足一個Server的基本特徵，能夠長時間運行

關於Http協議一般HttpServer都會聲明支持Http協議的哪些特性，nanohttpd作為一個輕量級的httpserver只實現了最簡單、最常用的功能，不過我們依然可以從中學習很多。

首先看下NanoHttpd類的start函數

[java] view plain
public void start() throws IOException {
myServerSocket = new ServerSocket();
myServerSocket.bind((hostname != null) ? new InetSocketAddress(hostname, myPort) : new InetSocketAddress(myPort));

myThread = new Thread(new Runnable() {
@Override
public void run() {
do {
try {
final Socket finalAccept = myServerSocket.accept();
registerConnection(finalAccept);
finalAccept.setSoTimeout(SOCKET_READ_TIMEOUT);
final InputStream inputStream = finalAccept.getInputStream();
asyncRunner.exec(new Runnable() {
@Override
public void run() {
OutputStream outputStream = null;
try {
outputStream = finalAccept.getOutputStream();
TempFileManager tempFileManager = tempFileManagerFactory.create();
HTTPSession session = new HTTPSession(tempFileManager, inputStream, outputStream, finalAccept.getInetAddress());
while (!finalAccept.isClosed()) {
session.execute();
}
} catch (Exception e) {
// When the socket is closed by the client, we throw our own SocketException
// to break the "keep alive" loop above.
if (!(e instanceof SocketException && "NanoHttpd Shutdown".equals(e.getMessage()))) {
e.printStackTrace();
}
} finally {
safeClose(outputStream);
safeClose(inputStream);
safeClose(finalAccept);
unRegisterConnection(finalAccept);
}
}
});
} catch (IOException e) {
}
} while (!myServerSocket.isClosed());
}
});
myThread.setDaemon(true);
myThread.setName("NanoHttpd Main Listener");
myThread.start();
}
1.創建ServerSocket，bind制定埠

2.創建主線程，主線程負責和client建立連接
3.建立連接後會生成一個runnable對象放入asyncRunner中，asyncRunner.exec會創建一個線程來處理新生成的連接。
4.新線程首先創建了一個HttpSession，然後while(true)的執行httpSession.exec。
這里介紹下HttpSession的概念，HttpSession是java里Session概念的實現，簡單來說一個Session就是一次httpClient->httpServer的連接，當連接close後session就結束了，如果沒結束則session會一直存在。這點從這里的代碼也能看到：如果socket不close或者exec沒有拋出異常（異常有可能是client段斷開連接）session會一直執行exec方法。
一個HttpSession中存儲了一次網路連接中server應該保存的信息，比如：URI，METHOD，PARAMS，HEADERS，COOKIES等。
5.這里accept一個client的socket就創建一個獨立線程的server模型是ThreadServer模型，特點是一個connection就會創建一個thread，是比較簡單、常見的socket server實現。缺點是在同時處理大量連接時線程切換需要消耗大量的資源，如果有興趣可以了解更加高效的NIO實現方式。

當獲得client的socket後自然要開始處理client發送的httprequest。

Http Request Header的parse：

[plain] view plain
// Read the first 8192 bytes.
// The full header should fit in here.
// Apache's default header limit is 8KB.
// Do NOT assume that a single read will get the entire header at once!
byte[] buf = new byte[BUFSIZE];
splitbyte = 0;
rlen = 0;
{
int read = -1;
try {
read = inputStream.read(buf, 0, BUFSIZE);
} catch (Exception e) {
safeClose(inputStream);
safeClose(outputStream);
throw new SocketException("NanoHttpd Shutdown");
}
if (read == -1) {
// socket was been closed
safeClose(inputStream);
safeClose(outputStream);
throw new SocketException("NanoHttpd Shutdown");
}
while (read > 0) {
rlen += read;
splitbyte = findHeaderEnd(buf, rlen);
if (splitbyte > 0)
break;
read = inputStream.read(buf, rlen, BUFSIZE - rlen);
}
}
1.讀取socket數據流的前8192個位元組，因為http協議中頭部最長為8192

2.通過findHeaderEnd函數找到header數據的截止位置，並把位置保存到splitbyte內。

[java] view plain
if (splitbyte < rlen) {
inputStream.unread(buf, splitbyte, rlen - splitbyte);
}

parms = new HashMap<String, String>();
if(null == headers) {
headers = new HashMap<String, String>();

}
1.http協議規定header和body之間使用兩個回車換行分割

1.Http協議第一行是Method URI HTTP_VERSION

2.後面每行都是KEY:VALUE格式的header
3.uri需要經過URIDecode處理後才能使用
4.uri中如果包含？則表示有param，httprequest的param一般表現為:/index.jsp?username=xiaoming&id=2

下面是處理cookie，不過這里cookie的實現較為簡單，所以跳過。之後是serve方法，serve方法提供了用戶自己實現httpserver具體邏輯的很好介面。在NanoHttpd中的serve方法實現了一個默認的簡單處理功能。

[java] view plain

發送response的步驟如下：

1.設置mimeType和Time等內容。
2.創建一個PrintWriter，按照HTTP協議依次開始寫入內容
3.第一行是HTTP的返回碼
4.然後是content-Type
5.然後是Date時間
6.之後是其他的HTTP Header
7.設置Keep-Alive的Header，Keep-Alive是Http1.1的新特性，作用是讓客戶端和伺服器端之間保持一個長鏈接。
8.如果客戶端指定了ChunkedEncoding則分塊發送response，Chunked Encoding是Http1.1的又一新特性。一般在response的body比較大的時候使用，server端會首先發送response的HEADER，然後分塊發送response的body，每個分塊都由chunk length\r\n和chunk data\r\n組成，最後由一個0\r\n結束。

9.如果沒指定ChunkedEncoding則需要指定Content-Length來讓客戶端指定response的body的size，然後再一直寫body直到寫完為止。

Ⅲ 面試中的網紅Vue源碼解析之虛擬DOM，你知多少呢深入解讀diff演算法

眾所周知，在前端的面試中，面試官非常愛考dom和diff演算法。比如，可能會出現在以下場景

滴滴滴，面試官發來一個面試邀請。接受邀請📞

我們都知道， key 的作用在前端的面試是一道很普遍的題目，但是呢，很多時候我們都只浮於知識的表面，而沒有去深挖其原理所在，這個時候我們的競爭力就在這被拉下了。所以呢，深入學習原理對於提升自身的核心競爭力是一個必不可少的過程。

在接下來的這篇文章中，我們將講解面試中很愛考的虛擬DOM以及其背後的diff演算法。 請認真閱讀本文～文末有學習資源免費共享！！！

虛擬DOM是用JavaScript對象描述DOM的層次結構。DOM中的一切屬性都在虛擬DOM中有對應的屬性。本質上是JS 和 DOM 之間的一個映射緩存。

要點：虛擬 DOM 是 JS 對象；虛擬 DOM 是對真實 DOM 的描述。

diff發生在虛擬DOM上。diff演算法是在新虛擬DOM和老虛擬DOM進行diff（精細化比對），實現最小量更新，最後反映到真正的DOM上。

我們前面知道diff演算法發生在虛擬DOM上，而虛擬DOM是如何實現的呢？實際上虛擬DOM是有一個個虛擬節點組成。

h函數用來產生虛擬節點（vnode）。虛擬節點有如下的屬性：
1）sel： 標簽類型，例如 p、div；
2）data： 標簽上的數據，例如 style、class、data-*；
3）children ：子節點；
4） text： 文本內容；
5）elm：虛擬節點綁定的真實 DOM 節點；

通過h函數的嵌套，從而得到虛擬DOM樹。

我們編寫了一個低配版的h函數，必須傳入3個參數，重載較弱。

形態1：h('div', {}, '文字')
形態2：h('div', {}, [])
形態3：h('div', {}, h())

首先定義vnode節點，實際上就是把傳入的參數合成對象返回。

[圖片上傳失敗...(image-7a9966-1624019394657)]
然後編寫h函數，根據第三個參數的不同進行不同的響應。

當我們進行比較的過程中，我們採用的4種命中查找策略：
1）新前與舊前：命中則指針同時往後移動。
2）新後與舊後：命中則指針同時往前移動。
3）新後與舊前：命中則涉及節點移動，那麼新後指向的節點，移到 舊後之後 。
4）新前與舊後：命中則涉及節點移動，那麼新前指向的節點，移到 舊前之前 。

命中上述4種一種就不在命中判斷了，如果沒有命中，就需要循環來尋找，移動到舊前之前。直到while(新前<=新後&&舊前<=就後)不成立則完成。

如果是新節點先循環完畢，如果老節點中還有剩餘節點(舊前和舊後指針中間的節點)，說明他們是要被刪除的節點。

如果是舊節點先循環完畢，說明新節點中有要插入的節點。

1.什麼是Virtual DOM 和Snabbdom
2.手寫底層源碼h函數
3.感受Vue核心演算法之diff演算法
4.snabbdom之核心h函數的工作原理

1、零基礎入門或者有一定基礎的同學、大中院校學生
2、在職從事相關工作1-2年以及打算轉行前端的朋友
3、對前端開發有興趣人群

Ⅳ 40K穩了！掌握Android-Framework源碼真是YYDS！

前兩天看到位元組一個老哥寫的帖子，提到高階開發者必須掌握的技能，其中他明確提出了「精通Framework」。

為啥Framework對Android開發人員如此重要？

我在面試的時候也經常看到一些程序員寫「精通Framework」，但 大多數人對精通存在一定誤區 。

Framework始終穿插在 App 整個研發生命周期中，不管是從 0 到 1 的建立階段，還是從 1 到 N 打磨階段，都離不開Framework 。所以與它相關的知識都尤為重要，面試官會通過連環炮來試探你相關技能的邊際所在。

對於大部分程序員來說，Framework用了很久，但依然會出現面對棘手問題束手無策的狀況，大多是因為 對源碼和底層原理模糊不清 。

為了幫助大家深刻理解Framework源碼，並將它應用到工作中，前段時間 整理收集的關於Android Framework的知識腦圖總結和源碼學習手冊文檔！ 既能夠 夯實底層原理、源碼解析等核心技術點，又能夠掌握普通開發者，難以觸及的復雜系統問題設計方案 。那你在工作中、團隊里、面試時，也就擁有了同行難以復制的核心競爭力。如果你正在進階這一塊，可以來參考Github上的這個 《Android Framework源碼解析手冊》

內容展示

作為過來人，發現很多學習者和實踐者都在 Android Framework上面臨著很多的困擾，比如：

總之，一旦遇到問題，很少人能夠由點及面逆向分析 ，最終找到瓶頸點和最優解決方案， 而Framework是Android開發的深水區，也是衡量一個Android程序員能力高低的標准。

Ⅳ 《深入理解SPARK核心思想與源碼分析》epub下載在線閱讀，求百度網盤雲資源

《深入理解SPARK》（耿嘉安）電子書網盤下載免費在線閱讀

資源鏈接：

鏈接：

書名：深入理解SPARK

作者：耿嘉安

豆瓣評分：7.2

出版社：機械工業出版社

出版年份：2016-1-1

頁數：469

內容簡介：

《深入理解SPARK：核心思想與源碼分析》結合大量圖和示例，對Spark的架構、部署模式和工作模塊的設計理念、實現源碼與使用技巧進行了深入的剖析與解讀。

《深入理解SPARK：核心思想與源碼分析》一書對Spark1.2.0版本的源代碼進行了全面而深入的分析，旨在為Spark的優化、定製和擴展提供原理性的指導。阿里巴巴集團專家鼎力推薦、阿里巴巴資深Java開發和大數據專家撰寫。

本書分為三篇：

准備篇（第1～2章），介紹了Spark的環境搭建、設計理念與基本架構，幫助讀者了解一些背景知識。

核心設計篇（第3～7章），著重講解SparkContext的初始化、存儲體系、任務提交與執行、計算引擎及部署模式的原理和源碼分析。通過這部分的內容，讀者可以通過源碼剖析更加深入理解Spark的核心設計與實現，以便在實際使用中能夠快速解決線上問題並對性能進行調優。

擴展篇（第8～11章），主要講解基於Spark核心的各種擴展及應用，包括SQL處理引擎、Hive處理、流式計算框架Spark Streaming、圖計算框架GraphX、機器學習庫MLlib等內容。通過閱讀這部分內容，讀者可以擴展實際項目中對Spark的應用場景，讓Spark煥發活力。

作者簡介：

耿嘉安，10年IT行業相關經驗。就職於阿里巴巴商家業務事業部，任資深Java工程師，專注於開源和大數據領域，目前與小夥伴們基於ODPS構建阿里的大數據商業解決方案——御膳房。在大量的工作實踐中，對J2EE、JVM、Tomcat、Spring、Hadoop、Spark、MySQL、Redis都有深入研究，尤其喜歡剖析開源項目的源碼實現。早期從事J2EE企業級應用開發，對Java相關技術有獨到見解。業余時間喜歡研究中國古代歷史，古詩詞，旅遊，足球等。

Ⅵ futex內核實現源碼分析（3）

futex同步機制包括用戶態的原子操作和內核態的futex系統調用兩部分組成，其調用原型如下：

在futex系統調用內部是通過do_futex()完成具體操作

futex系統調用的參數很多，而do_futex的參數比futex還要多出一個來。這是由於同一個futex調用要根據不同的操作類型來完成不同的操作，而具體的操作所需的參數因目的不同而有所差異，每種具體的操作類型所需的參數數目以及具體參數的含義由其參數op決定。具體op操作類型的定義具體如下：

具體的futex系統調用如下，在futex(……)中根據操作類型op對參數進行調整，然後調用do_futex(……)。主要有以下幾種情況：

在do_futex(……)中，主要根據op代表的具體操作類型進行不同分支的操作。例如FUTEX_WAIT執行futex_wait(uaddr, flags, val, timeout, val3)，FUTEX_WAKE則執行futex_wake(uaddr, flags, val, val3)，這是最基本futex阻塞喚醒操作。可以看到FUTEX_WAIT_BITSET和FUTEX_WAKE_BITSET最終調用的具體操作函數也是futex_wait(uaddr, flags, val, timeout, val3)和futex_wake(uaddr, flags, val, val3)，只不過FUTEX_WAIT和FUTEX_WAKE在執行具體操作之前將bitset參數val3設置為全匹配。另外操作函數中flag參數指明該futex變數時進程間共享的還進程私有的，該參數具體值根據op的值設定。

後面會主要對futex_wait(……)和futex_wake(……)進行詳細分析。

參考：
http://www.tuicool.com/articles/feUR73
http://blog.csdn.net/jianchaolv/article/details/7544316

Ⅶ futex內核實現源碼分析（2）

由上一章節可知，futex變數創建於用戶空間，在進程或線程間共享，當進程或線程想要進入臨界區時，通常會判斷futex變數是否滿足條件，若滿足則成功進入臨界區，否則則阻塞在該futex變數上；當進程或線程將要離開臨界區時，則會喚醒阻塞在futex變數上的其他進程或線程。在內核中通過struct futex_q結構將一個futex變數與一個掛起的進程（線程）關聯起來。

struct futex_q：

union futex_key：futex變數地址標識

在內核中通過一個哈希表來維護所有掛起阻塞在futex變數上的進程（線程），不同的futex變數會根據其地址標識計算出一個hash key定位到一個哈希桶鏈上，因此掛起阻塞在同一個futex變數的所有進程（線程）會定位到同一個哈希桶鏈上。

struct futex_hash_bucket ：

futex哈希表：

同一進程下不同線程阻塞在futex變數模型：

內核fuetx初始化，初始化futex哈希表的每一個哈希桶鏈的頭。

Ⅷ 深入理解spark核心思想與源碼分析 怎麼樣

SparkSQL主要的推動者是Databricks。提到SparkSQL不得不提的就是Shark。Shark可以理解為Spark社區這邊搞的一個」HiveonSpark」，把Hive的物理執行計劃使用Spark計算引擎去執行。這裡面會有一些問題，Hive社區那邊沒有把物理執行計劃到執行引擎這個步驟抽象出公共API，所以Spark社區這邊要自己維護一個Hive的分支，而且Hive的設計和發展不太會考慮到如何優化Spark的Job。但是前面提到的HiveonSpark卻是和Hive一起發布的，是由Hive社區控制的。所以後來Spark社區就停止了Shark的開發轉向SparkSQL（「坑了」一部分當時信任Shark的人）。SparkSQL是把SQL解析成RDD的transformation和action，而且通過catalyst可以自由、靈活的選擇最優執行方案。對資料庫有深入研究的人就會知道，SQL執行計劃的優化是一個非常重要的環節，SparkSQL在這方面的優勢非常明顯，提供了一個非常靈活、可擴展的架構。但是SparkSQL是基於內存的，元數據放在內存裡面，不適合作為數據倉庫的一部分來使用。所以有了SparkSQL的HiveContext，就是兼容Hive的SparkSQL。它支持HiveQL,HiveMetastore,HiveSerDesandHiveUDFs以及JDBCdriver。這樣看起來很完美，但是實際上也有一些缺點：SparkSQL依賴於Hive的一個snapshot，所以它總是比Hive的發布晚一個版本，很多Hive新的feature和bugfix它就無法包括。而且目前看Spark社區在Spark的thriftserver方面的投入不是很大，所以感覺它不是特別想朝著這個方向發展。還有一個重要的缺點就是SparkSQL目前還不能通過分析SQL來預測這個查詢需要多少資源從而申請對應的資源，所以在共享集群上無法高效地分配資源和調度任務。

Ⅸ 直播源碼都有哪些核心功能開發

所謂直播系統源碼，直播間功能當然是必須存在的，並且隨著直播行業的發展，直播間的種類也在不斷增加，計時收費直播間、密碼直播間等變種不斷出現，比如：
計時收費直播間：粉絲按照直播時長支付一定費用，該直播間能夠有效提升主播收入，並且一些忠實用戶會很喜歡。
密碼直播間：主播會在開播之前設定直播間的密碼，粉絲只有輸入正確的密碼才可以進入直播間觀看直播，這種房間可以被用於開辦小型粉絲見面會。
一對一直播間：主播在一定時間內只能與一名用戶進行連麥，這對一些忠實粉絲和土豪粉絲非常友善。付費直播間：主播在開播時設定好直播間的收費標准，粉絲需要支付一定的費用才可以進入直播間。直播列表：關注、熱門、最新、新人、分類列表等主播直播列表是以多種演算法進行區分的，比如熱門是根據主播收到禮物的多少進行曝光排序，新人列表可能是以主播的入駐時間進行排序，關注列表則是以用戶是否關注了該主播為決定性因素，這些直播列表也是從不同維度提升主播的曝光量。禮物功能：前端的普通禮物、豪華禮物、紅包、商城等功能，後台的支付寶、微信、第三方介面等功能都是，禮物功能是主播和平台的收入來源之一，該功能必不可少。

Ⅹ Netty核心技術及源碼剖析-Netty入站與出站機制

1、Netty的組件設計: Netty的主要組件有Channel、EventLoop、ChannelFuture、ChannelHandler、ChannelPipe等。
2、ChannelHandler充當了處理入站和出站數據的應用程序邏輯的容器。例如,實現ChannelInboundHandler介面(或ChannelInboundHandlerAdapter),你就可以接收入站事件和數據,這些數據會被業務邏輯處理。當要給客戶端發送響應時,也可以從ChannelInboundHandler沖刷數據。業務邏輯通常寫在一個或者多個ChannelInboundHandler中。ChannelOutboundHandler原理一樣,只不過它是用來處理出站數據的。
3、ChannelPipeline提供了ChannelHandler鏈的容器。以客戶端應用程序為例,如果事件的運動方向是從客戶端到服務端的,那麼我們稱這些事件為出站的,即客戶端發送給伺服器端的數據會通過pipeline中的一些列ChannelOutboundHandler,並被這些Handler處理,反之則稱為入站的。

1、當Netty發送或者接受一個消息的時候,就將會發生一次數據轉換。入站消息會被解碼:從位元組轉換為另一種格式(比如Java對象);如果是出站消息,它會被編碼成位元組。
2、Netty提供一些列實用的編解碼器,他們都實現了ChannelInboundHandler或者ChannelOutboundHandler介面。在這些類中,channelRead方法已經被重寫了。以入站為例,對於每個從入站Channel讀取的消息,這個方法會被調用。隨後,它將調用由解碼器所提供的decode()方法進行解碼,並將已經解碼的位元組轉發給ChannelPipeline中的下一個ChannelInboundHandler。

1、關系繼承圖

2、由於不可能知道遠程節點是否會一次性發送一個完整的信息,tcp有可能出現粘包拆包的問題,這個類會對入站數據進行緩沖,知道它准備好被處理。
3、一個關於ByteToMessageDecoder實例分析