源起
小飛是壹名剛入行前端不久的新人,因為進到了某個大公司,儼然成為了學弟學妹眼中'大神',大家遇到js問題都喜歡問他,這不,此時他的qq彈出了這樣壹條消息
"hi,大神在嗎?我有個問題想問,現在我們的代碼裏面有這樣的東西,可是得不到正確的返回結果
1234567function?getDataByAjax () {return?$.ajax(...postParam)}var?data = getDataByAjax()if?(data) {console.log(data.info)}"哦,妳這裏是異步調用,不能直接獲得返回值,妳要把if語句寫到回調函數中",小飛不假思索的說到,對於壹個‘專業’的fe來說,這根本不是壹個問題。
“可是我希望只是改造getDataByAjax這個方法,讓後面的代碼成立。”
“研究這個沒有意義,異步是js的精髓,同步的話會阻塞js調用,超級慢的,但是妳要壹再堅持的話,用async:true就好了”
“不愧是大神,我回去立刻試壹試,麽麽噠”
兩天後,她哭喪著臉登上了qq
“試了壹下妳的方法,但是根本行不通,哭~~”
“別急,我看看妳這個postParam的參數行嗎”
123456{...dataType:?'jsonp',async:?true...}"這是壹個jsonp請求啊,老掉牙的東西了,,jsonp請求是沒有辦法同步的"
“我知道jsonp請求的原理是通過script標簽實現的,但是,妳看,script也是支持同步的呀,妳看tags/attscriptasync.asp”
“額,那可能是jquery沒有實現吧,哈哈”
“大神,妳能幫我實現壹個jsonp的同步調用方式嘛,拜托了(星星眼)”
雖然他有點奇怪jquery為什麽沒有實現,但是既然w3school的標準擺在那裏,碼兩行代碼又沒什麽,
1234567891011121314export?const loadJsonpSync = (url) => {var?result;?window.callback1 = (data) => (result = data)let?head = window.document.getElementsByTagName('head')[0]let?js = window.document.createElement('script')?js.setAttribute('type',?'text/javascript')?js.setAttribute('async',?'sync')?// 這句顯式聲明強調src不是按照異步方式調用的?js.setAttribute('src', url)?head.appendChild(js)return?result}額,運行起來結果竟然是undefined!w3cshool的文檔竟然也不準,還權威呢,我看也不怎麽著,小飛暗自想到。
“剛才試了壹下,w3school文檔上寫的有問題,這個異步屬性根本就是錯的”
“可是我剛還試過壹次這個,我確認是好的呀”
12<script src="loop50000 && put('frist').js"></script><script src="put('second').js"></script>(有興趣的同學可以實現以下兩個js,並且加上async的標簽進行嘗試。)
“這個,我就搞不清楚了”,小飛訕訕的說到
對方已離線
抽象
關於這個問題,相信不只是小飛,很多人都難以解答。為什麽ajax可以做到同步,但jsonp不行,推廣到nodejs上,為什麽readFile也可以做到同步(readFileSync),但有的庫卻不行。
(至於script的async選項我們暫時避而不談,是因為現在的知識維度暫時還不夠,但是不要著急,下文中會給出明確的解釋)
現在,讓我們以計算機科學的角度抽象這個問題:
我們是否可以將異步代碼轉化為同步代碼呢?(ASYNCCALL => SYNCCALL)
既然是抽象問題,那麽我們就可以不從工程角度/性能角度/實現語言等等等方面來看(同步比異步效率低下),每增加壹個維度,復雜程度將以幾何爆炸般增長下去。
首先,我們來明確壹點,==在計算機科學領域==同步和異步的定義
同步(英語:Synchronization),指對在壹個系統中所發生的事件(event)之間進行協調,在時間上出現壹致性與統壹化的現象。在系統中進行同步,也被稱為及時(in time)、同步化的(synchronous、in sync)。--摘自百度百科
異步的概念和同步相對。即時間不壹致,不統壹
明確了這壹點,我們可以借助甘特圖來表示同步和異步
其中t1和t2是同步的,t1和t3是異步的。
答案就在操作系統原理的大學教材上,我們有自旋鎖,信號量來解決問題,偽代碼如下
1234567891011121314151617spinLock () {// 自旋鎖?fork Wait 3000 unlock()?//開啟壹個異步線程,等待三秒後執行解鎖動作?loop until unlock?// 不斷進行空循環直到解鎖動作Put ‘unlock’}?//pv原語,當信號量為假時立即執行下壹步,同時將信號量置真//反之將當前執行棧掛起,置入等待喚醒隊列//uv原語,將信號量置為假,並從等待喚醒隊列中喚醒壹個執行棧Semaphore () {?pv()?fork Wait 3000 uv()?pv()?uv()Put?'unlock'}很好,至此都可以在操作系統原理的教材上翻到答案。於是我們在此基礎上添加約束條件
僅僅依賴於js本身,我們是否可以將異步代碼轉化為同步代碼呢?(ASYNCCALL => SYNCCALL)
論證
帶著這個問題,我們翻看壹下jquery的源碼
src/ajax/xhr.js#L42
可以看出, ajax的同步機制本質上是由XMLHttpRequest實現的,而非js原生實現。
同樣的道理,我們再翻看壹下nodejs的源碼
lib/fs.js#L550
從readFileSync->tryReadSync->readSync壹路追下去,會追到壹個c++ binding, node_file.cc#L1167
123456if?(req->IsObject()) {ASYNC_CALL(read, req, UTF8, fd, &uvbuf, 1, pos);}?else?{SYNC_CALL(read, 0, fd, &uvbuf, 1, pos)args.GetReturnValue().Set(SYNC_RESULT);}同步的奧妙在於c++的宏定義上,這是壹種借由c++來實現的底層同步方式。
觀察了這兩種最廣泛的異步轉同步式調用,我們發現均沒有采用js來實現。
似乎從現象層面上來看js無法原生支持,但是這還不夠,我們探究在js語義下上面的自旋鎖/信號量的特性模擬實現(我知道妳們壹定會嗤之以鼻,==js本身就是單線程的,只是模擬了多線程的特性== 我無比贊同這句話,所以這裏用的不是實現,而是特性模擬實現),另外,由於settimeout具有fork相似的異步執行特性,所以我們用setitmeout暫時代替fork
自旋鎖
1.第壹個實現版本
1234567var?lock =?truesetTimeout(function?() {lock =?false}, 5000)?while(lock);console.log('unlock')我們預期在5000ms後執行unlock語句,但是悲劇的是,整個chrome進程僵死掉了。
為了解釋清楚這個問題,我們讀壹下阮壹峰老師的event loop模型
event-loop.html
看樣子咱們已經清楚的了解了event loop這個js運行順序的本質(同步執行代碼立即執行,異步代碼入等待隊列),那麽,我們可以基於此給出js vm的調度實現(eventloop的壹種實現),當然,咱們為了解釋自旋鎖失敗只需要模擬異步操作, 同步操作,和循環就好
123456789101112131415161718192021222324//taskQueue:任務隊列//runPart:當前正在執行的任務(同步指令集)//instruct: 正在執行的指令?function?eventloop (taskQueue) {while(runPart = taskQueue.shift()) {while(instruct = runPart.shift()) {const { type, act, codePart } = instructswitch(type) {case?'SYNC':?console.log(act)if?(act ===?'loop')runPart.unshift({?act:?'loop',?type:?'SYNC'})breakcase?'ASYNC':?taskQueue.push(codePart)break}}}}然後轉化我們的第壹個版本自旋鎖
1234567891011121314151617181920let?taskQueue = [[{act:?'var lock = true', type:?'SYNC'},?//var lock = true{act:?'setTimeout',type:?'ASYNC',codePart: [{act:?'lock = false', type:?'SYNC'}]},?// setTimeout(function () { lock = false }, 5000)/*{act: 'loop',type: 'SYNC'},*/?// while(lock);{act:?'console.log(\'sync\')',type:?'SYNC'}?// console.log('unlock')]]<em id="__mceDel">?</em>測試壹下,符合evnet loop的定義,然後放開註釋,我們成功的讓loop block住了整個執行過程,lock = false永遠也沒有機會執行!!!
(真實的調度機制遠比這個復雜的多得多的,有興趣的可以看看webkit~~~的jscore的實現哈)
知道了原理,我們就來手動的改進這部分代碼
2.改進的代碼
12345678910111213141516var?lock =?truesetTimeout(function?() {lock =?falseconsole.log('unlock')}, 5000)?function?sleep() {var?i = 5000while(i--);}?var?foo = () => setTimeout(function?() {sleep()lock && foo()})foo()這個版本的改進我們對while(true);做了切塊的動作,實際上這種技巧被廣泛的應用到改善頁面體驗的方面,所以,有些人因為時序無法預知而抗拒使用settimeout這種想法是錯誤的!
6996528,
小測驗1: 改寫eventloop和taskQueue,使它支持改進後的代碼
可是,如果把代碼最後的foo() 變成 foo() && console.log('wait5sdo'),
我們的代碼依然沒有成功,why
註意看我們標紅的地方,如果妳完成了小測驗1,就會得到和這張圖壹致的順序
==同步執行的代碼片段必然在異步之前。==
所以,無論從理論還是實際出發,我們都不得不承認,在js中,把異步方法改成同步方法這個命題是水月鏡花
哦對了,最後還需要解釋壹下最開始我們埋下的坑, 為什麽jsonp中的async沒有生效,現在解釋起來真的是相當輕松,即document.appendChild的動作是交由dom渲染線程完成的,所謂的async阻塞的是dom的解析,而非js引擎的阻塞。實際上,在async獲取資源後,與js引擎的交互依舊是push taskQueue的動作,也就是我們所說的async call
推薦閱讀: 關於dom解析請大家參考webkit技術內幕第九章資源加載部分
峰回路轉
相信很多新潮的同學已經開始運用切了async/await語法,在下面的語法中,getAjax1和console之間的具有同步的特性
1234async?function?() {var?data = await getAjax1()console.log(data)}講完了event loop和異步的本質,我們來重新審視壹下async/await。
老天,這段代碼親手推翻了==同步執行的代碼片段必然在異步之前。== 的黃金定律!
驚不驚喜,意不意外,這在我們的模型裏如同三體裏的質子壹樣的存在。我們重新審視了壹遍上面的模型,實在找不到漏洞,找不到任何可以推翻的點,所以真的必須承認,async/await絕對是壹個超級神奇的魔法。
到這裏來看我們不得不暫時放棄前面的推論,從async/await本身來看這個問題
相信很多人都會說,async/await是CO的語法糖,CO又是generator/promise的語法糖,好的,那我們不妨去掉這層語法糖,來看看這種代碼的本質, 關於CO,讀的人太多了,我實在不好老生常談,可以看看這篇文章,咱們就直接繞過去了,這裏給出壹個簡易的實現
/5800210.html
1234567891011121314151617181920function?wrap(wait) {var?iter?iter = wait()const f = () => {const { value } = iter.next()value && value.then(f)}?f()}?function?*wait() {var?p = () =>?new?Promise(resolve => {?setTimeout(() => resolve(), 3000)})yield?p()?console.log('unlock1')yield?p()?console.log('unlock2')?console.log('it\'s sync!!')}終於,我們發現了問題的關鍵,如果單純的看wait生成器(註意,不是普通的函數),是不是覺得非常眼熟。這就是我們最開始提出的spinlock偽代碼!!!
這個已經被我們完完全全的否定過了,js不可能存在自旋鎖,事出反常必有妖,是的,yield和*就是表演async/await魔法的妖精。
generator和yield字面上含義。Gennerator叫做生成器,yield這塊ruby,python,js等各種語言界爭議很大,但是大多數人對於‘讓權’這個概念是認同的(以前看到過maillist上面的爭論,但是具體的內容已經找不到了)
擴展閱讀---ruby元編程 閉包章節yield(ruby語義下的yield)
所謂讓權,是指cpu在執行時讓出使用權利,操作系統的角度來看就是‘掛起’原語,在eventloop的語義下,似乎是暫存起當時正在執行的代碼塊(在我們的eventloop裏面對應runPart),然後順序的執行下壹個程序塊。
我們可以修改eventloop來實現讓權機制
小測驗2 修改eventloop使之支持yield原語
至此,通過修改eventloop模型固然可以解決問題,但是,這並不能被稱之為魔法。
和諧***存的世界
實際上通過babel,我們可以輕松的降級使用yield,(在es5的世界使用讓權的概念!!)
看似不可能的事情,現在,讓我們撿起曾經論證過的
==同步執行的代碼片段必然在異步之前。== 這個定理,在此基礎上進行進行逆否轉化
==在異步代碼執行之後的代碼必然不是同步執行的(異步的)。==
這是壹個圈子裏人盡皆知的話,但直到現在他才變得有說服力(我們繞了壹個好長的圈子)
現在,讓我們允許使用callback,不使用generator/yield的情況下完成壹個wait generator相同的功能!!!
1234567891011121314151617181920function?wait() {const p = () => ({value:?new?Promise(resolve => setTimeout(() => resolve(), 3000))})let?state = {next: () => {state.next = programPartreturn?p()}}function?programPart() {?console.log('unlocked1')?state.next = programPart2return?p()}function?programPart2() {?console.log('unlocked2')?console.log('it\'s sync!!')return?{value: void 0}}return?state}太棒了,我們成功的完成了generator到function的轉化(雖然成本高昂),同時,這段代碼本身也解釋清楚了generator的本質,高階函數,片段生成器,或者直接叫做函數生成器!這和scip上的翻譯完全壹致,同時擁有自己的狀態(有限狀態機)
推薦閱讀 計算機程序的構造和解釋 第壹章generator部分
小測驗3 實際上我們提供的解決方式存在缺陷,請從作用域角度談談
其實,在不知不覺中,我們已經重新發明了計算機科學中大名鼎鼎的CPS變換
Continuation-passing_style
最後的最後,容我向大家介紹壹下facebook的CPS自動變換工具--regenerator。他在我們的基礎上修正了作用域的缺陷,讓generator在es5的世界裏自然優雅。我們向facebook脫帽致敬!!egenerator
後記
同步異步 可以說是整個圈子裏面最喜歡談論的問題,但是,談來談去,似乎絕大多數變成了所謂的‘約定俗稱’,大家意味追求新技術的同時,卻並不關心新技術是如何在老技術上傳承發展的,知其然而不知其所以然,人雲亦雲的寫著似是而非的js。
==技術,不應該浮躁==
PS: 最大的功勞不是CO,也不是babel。regenerator的出現比babel早幾個月,而且最初的實現是基於esprima/recast的,關於resprima/recast,國內似乎了解的並不多,其實在babel剛剛誕生之際, esprima/esprima-fb/acron 以及recast/jstransfrom/babel-generator幾大族系圍繞著react產生過壹場激烈的鬥爭,或許將來的某壹天,我會再從實現細節上談壹談為什麽babel笑到了最後~~~~