js機制實例詳解（js基礎案例）

本文目錄一覽：

• 1、我對JS異步執行機制的理解
• 2、請說明javascript的繼承機制和java繼承機制的區別
• 3、北大青鳥java培訓：js解析機制與閉包分析？

我對JS異步執行機制的理解

說起JS的異步執行機制，如果百度一下，你首先會發現阮一峰的寫過一篇關於異步機制的文章（ ），等你津津有味又一頭霧水的看完，然後繼續看百度的其他結果，然後會發現，阮一峰的這篇被另一個大牛朴靈給批判了

（ ）。

由此可見，關於異步執行機制到底是怎麼回事，因為涉及到瀏覽器底層機制，所以不容易徹底了解清楚，就算是大牛阮一峰，也只是通過英文文獻來了解，而且一知半解。我的這篇文章只是試圖儘可能簡單的描述一下JS的異步執行機制，坦白說，我現在並不能完全弄懂這個機制，所以也不能完全解釋清這個機制，所以，如果我寫的越嚴謹，就越容易出錯，我只能簡單但是較模糊的描述一下：

JS的運行環境是一個很複雜的環境，它裏面有非常多的複雜的名詞事物，用簡單又不嚴謹的說法來說，運行環境里至少有下面這些事物：

有一個國外的web app，專門用來講解異步事件的門道 Loupe ，這個更接近真實情況。為什麼我不講解這個？因為更複雜了，我們並不打算研究瀏覽器的底層，不是么？

然後說一下任務隊列里的任務。所有任務可以分成兩種，一種是同步任務（synchronous），另一種是異步任務（asynchronous）。同步任務指的是，靠主線程自己就可以執行完成的任務；異步任務指的是，主線程執行開始之後，需要靠主線程之外的線程才能完成的任務。由主線程決定是否要動用其他線程。以下內容，不再提棧，只說主線程。

現在說重點：

異步任務的執行機制是：

當主線程遇到一個異步任務，比如一個ajax請求，當主線程執行到 xhr.send() 的時候，這個send命令是立即執行的， 並不會像一些人想像的，拖到所有同步任務的最後面。 然後主線程向http線程發送指令，要求http線程向服務器發送請求。這裡強調一下http線程，顯然它不是主線程的一部分，因為它可以並發，如果你有100個ajax請求，每個都需要1秒鐘，是不是http線程要花100秒呢？並不是，它會並發100個請求，總共耗時大約1.01秒就完成了。

主線程向以http線程為代表的幾個線程發送指令之後，主線程就暫時不再管這個ajax任務了，而是去看任務隊列里的下一個任務。

http線程發送了請求之後接收反饋，收到之後，形成一個新的事件（可以叫做「我收到啦！」事件），然後插入到回調函數隊列中，因為回調函數隊列的優先級很低，所以會排到總隊列的最後面，其結果就是：主線程把同步任務都完成了，才開始執行異步事件的 回調 。 注意，並不是異步任務在全體同步任務結束之後才開始，而是異步任務的回調通常在全體同步任務結束之後才開始！異步任務跟異步任務的回調是兩回事！是兩個任務！一個鮮明的例子就是 setTimeout(fn, 1000) ，計時是從主線程遇到 setTimeout() 任務，然後分配給計時器線程，計時器線程開始幹活的時候就開始計時了！只不過要1秒之後 fn 才執行！ setTimeout() 和 fn 是兩個任務！ setTimeout() 是立即執行， fn 才是1秒之後執行。但是 setTimeout() 的執行，人眼是感受不到的，因為並沒有什麼地方有一個秒錶告訴你 setTimeout() 開始執行了；而fn的執行，人眼能感受到，所以人們會錯誤的以為fn才是異步任務，其實fn並不是， fn 是個回調任務，往往 fn 是同步任務，比如 fn 可能是 console.log(123) ，這怎麼會是異步任務。

所以，異步機制是瀏覽器的兩個或以上常駐線程共同完成的，異步請求是JS主線程和其他某個線程共同完成的，JS的執行線程發起異步請求（這時瀏覽器會開一條新的HTTP請求線程來執行請求，這時JS自己的任務已完成，繼續執行線程隊列中剩下的其他任務），然後在未來的某一時刻”任務隊列”線程監視到之前的發起的HTTP請求已完成， “任務隊列”就會把完成事件插入到JS執行隊列的尾部等待JS處理 。

最後專門說說定時觸發（settimeout和setinterval）。

定時觸發是由瀏覽器的定時器線程執行的定時計數， 然後在定時時間到達之後，定時器線程把定時處理函數的執行請求插入到JS回調隊列的尾端。

這個1到底是100毫秒之後彈出，還是1000毫秒（或更多時間）後彈出呢？又或是1100毫秒之後彈出？

答案是，1000毫秒多一點點之後彈出。

原因：瀏覽器會先執行setTimeout，也就是開始計時，然後開始執行sometask，執行了1000毫秒，然後去回調隊列里看回調任務，alert(1);早就恭候了，因為定時100毫秒之後alert(1)就可以執行了。所以，等1000毫秒的任務完成，1就會立即彈出，所以答案是1000毫秒多一點點之後彈出。

所以用這兩個函數的時候，實際的執行時間是大於或等於指定時間的，不保證能準確定時的。

最後強調一下setInterval。比如我希望每100毫秒打印一個1。然後，又有極端情況，就是sometask耗時1000毫秒。你以為sometask結束之後會打出10個1么？並不會，只會打出1個1，因為setInterval第一次讀秒結束之後，回調隊列出現了一個alert(1)，根據之前的理論，並不會執行。又過了100毫秒之後，計時器線程會去觀察回調隊列是不是已經有了alert(1)，如果有，就不再往回調隊列里加alert(1)，目的就是為了避免回調疊加執行。

總之，你需要記住，異步任務就是主線程在任務隊列里看到了這個任務，看了一眼之後就然後安排別的線程幫忙，然後主線程就忙別的去了，別的線程幫忙完事之後，再在隊列末尾放一個新任務叫「幫忙完畢」，到此異步任務本身就完事。主任務看到「幫忙完畢」任務之後，就去執行回調，回調執行完，這個異步任務連同回調就全都完事。然後，如果並沒有回調。。。沒有就沒有唄。

請說明javascript的繼承機制和java繼承機制的區別

一，先來說說javascript的繼承機制的幾種方式：

1，原型鏈繼承：

優點：從instanceof關鍵字來看，實例既是父類的實例，又是子類的實例，看起來似乎是最純粹的繼承。

缺點：子類區別於父類的屬性和方法，必須在Sub.prototype = new Base();這樣的語句之後分別執行，無法被包裝到Sub這個構造器裏面去。例如：Sub.prototype.name = 「sub」；無法實現多重繼承。

2，構造繼承：

優點：可以實現多重繼承，可以把子類特有的屬性設置放在構造器內部。

缺點：使用instanceof發現，對象不是父類的實例。

3，實例繼承：

優點：是父類的對象，並且使用new構造對象和不使用new構造對象，都可以獲得相同的效果。

缺點：生成的對象實質僅僅是父類的實例，並非子類的對象；不支持多繼承。

4，拷貝繼承：

優點：支持多繼承。

缺點：效率較低；無法獲取父類不可枚舉的方法。

二，java繼承機制：

1，java里的類不能多重繼承，如果一個類一旦繼承了它的父類，那麼它就別想再繼承別的類。一個兒子只能有一個老爸，原本設計是沒錯的。可是在實際應用中，就會出現各種問題。

2，java里有更好的接口，接口從本質上來說可以更好的代替繼承。實現像C++里一樣的宏定義的功能，把你想要的東西都抽象在接口裡，讓具體的類去實現這些功能。

三，綜上可以看出java不能多繼承，javascript可以，但是javascript沒有接口這一說話，也有局限性，各有千秋吧。

北大青鳥java培訓：js解析機制與閉包分析？

隨着互聯網的不斷發展，程序員在學習JavaScript編程開發上也有了更多的了解，今天我們就簡單分析一下關於JavaScript編程解析機制以及閉包的一些常見問題。

js解析機制：js代碼解析之前會創建一個如下的詞法環境對象(倉庫)：LexicalEnvironment{}在掃描js代碼時會把：1、用聲明的方式創建的函數的名字;2、用var定義的變量的名字存到這個詞法環境中;3、同名的時候：函數聲明會覆蓋變量，下面的函數聲明會覆蓋上面的同名函數;4、函數的值為：對函數的一個引用;變量的值為undefined;5、如果用函數表達式的方式創建一個函數：varfn=function(){}這樣詞法環境中存的是一個變量名fn，並賦值為undefined;在調用函數的時候如果在函數上面調用就會出現和變量一樣的情況報錯undefined;這也是以兩種不同方式創建函數的區別;閉包：定義：(有多種定義)1、(比較通俗的定義)：函數嵌套函數，內部函數可以引用外部函數的參數和變量，這些參數和變量不會被垃圾回收機制所回收;2、在計算機科學中，閉包是詞法閉包的簡稱，是引用了自由變量的函數，這個被引用的自由變量將和這個函數一同存在，即使已經離開了創造它的環境也不例外(意思就是不會被銷毀)。

3、閉包是由函數和其相關的引用環境組合而成的實體。

(潛台詞就是這個函數將和引用環境同時存在，必須有引用)綜合來說，不管怎麼定義都是在圍繞着兩個本質：函數在引用變量，這個變量將不會被銷毀。

閉包的一個作用就是：我們能夠通過閉包的方法來在外部訪問到一個內部函數的變量;很多人在解釋閉包的時候都會把子函數return出去以後在外部調用，其實無論在哪裡調用，閉包都已經形成了，只要是函數嵌套函數，並且子函數引用了父函數的變量，(不論子函數有沒有被調用，電腦培訓認為這個用一種方法證明：在子函數內部打斷點，在f12中觀察閉包里的內容，已經出現了引用函數，這時候調用還沒有被執行)這個時候閉包已經形成了。