摘要：一垃圾回收與內(nèi)存泄漏參考內(nèi)存控制垃圾回收的垃圾回收策略主要基于分代式垃圾回收機(jī)制。內(nèi)存泄漏內(nèi)存泄漏的實(shí)質(zhì)就是應(yīng)當(dāng)回收的對(duì)象因?yàn)橐馔鉀](méi)有被回收，變成了常駐在老生代中的對(duì)象。造成內(nèi)存泄漏的主要原因有緩存隊(duì)列消費(fèi)不及時(shí)作用域未釋放。

1.內(nèi)存泄漏與垃圾回收
2.cookie和session
3.單線程原理
4.上下左右居中的幾種實(shí)現(xiàn)。
5.BFC和IFC模型。

參考：內(nèi)存控制

v8的垃圾回收策略主要基于分代式垃圾回收機(jī)制。按照對(duì)象的存活時(shí)間將內(nèi)存的垃圾回收進(jìn)行不同的分代，然后，分別對(duì)不同的分代的內(nèi)存再進(jìn)行高效的垃圾回收算法。在V8中，主要將內(nèi)存分為新生代和老生代兩代。新內(nèi)存中的對(duì)象存活時(shí)間短，老內(nèi)存中的對(duì)象存活時(shí)間長(zhǎng)或常駐內(nèi)存對(duì)象。

1）新生代垃圾回收算法scavenge算法

新生代中的對(duì)象主要通過(guò)scavenge算法進(jìn)行垃圾回收，其主要是采用cheney算法進(jìn)行具體處理。

cheney算法采用一種復(fù)制方式的垃圾回收算法，將堆內(nèi)存一分為二，只有一部分空間被使用稱為From空間，另一個(gè)處于閑置稱為To空間。當(dāng)進(jìn)行分配對(duì)象的時(shí)候先在from空間分配，當(dāng)進(jìn)行垃圾回收時(shí)，會(huì)檢查from空間中的存活對(duì)象，將這些存活對(duì)象復(fù)制到to空間中,復(fù)制完成后From和to空間角色互換，清空to空間，在垃圾回收過(guò)程中就是通過(guò)將存活對(duì)象在兩個(gè)空間中進(jìn)行復(fù)制。

缺點(diǎn)： 只能使用一半的內(nèi)存

優(yōu)點(diǎn)： 只復(fù)制存活的對(duì)象，對(duì)于生命周期短的場(chǎng)景存活對(duì)象只占小部分，所以時(shí)間效率高

當(dāng)一個(gè)對(duì)象經(jīng)過(guò)多次復(fù)制依然存活時(shí)，就會(huì)被認(rèn)為是生命周期較長(zhǎng)的對(duì)象，會(huì)被移入老生代內(nèi)存中。

對(duì)于移入老生代內(nèi)存有兩個(gè)條件：

對(duì)象已經(jīng)經(jīng)過(guò)新生代內(nèi)存回收機(jī)制的回收依然存活

復(fù)制到To空間的對(duì)象超過(guò)25%（為什么是25%？這個(gè)To空間接下來(lái)會(huì)成為From空間并接受內(nèi)存分配，如果占比過(guò)高影響后續(xù)分配）

2）老內(nèi)存垃圾回收算法Mark-Sweep & Mark-Compact

老內(nèi)存中，大多是不死的老對(duì)象，用scavenge算法又費(fèi)力，又占用空間，因此，采用了新的內(nèi)存垃圾回收算法：Mark-Sweep & Mark-Compact。

Mark-Sweep 標(biāo)記清掃

mark-sweep分為標(biāo)記和清除兩個(gè)階段，mark階段會(huì)遍歷堆，然后標(biāo)記處活著的對(duì)象，sweep階段會(huì)清除沒(méi)有被標(biāo)記的對(duì)象。mark-sweep只清理沒(méi)有標(biāo)記的對(duì)象，在老內(nèi)存中，死了的對(duì)象占比較少，這也是這個(gè)算法高效的原因。

mark-sweep的問(wèn)題在于，每次sweep后，會(huì)存在內(nèi)存碎片，這些不連續(xù)的內(nèi)存碎片會(huì)占有大量空間，因此，下一次復(fù)制大對(duì)象時(shí)，將會(huì)發(fā)現(xiàn)空間不夠，因而再次觸發(fā)垃圾回收，這個(gè)回收是不必要的，也浪費(fèi)了cpu。為了解決這個(gè)問(wèn)題，增加了mark-compact算法。

mark-compact 標(biāo)記整理和壓縮
mark-compact在整理過(guò)程中，將活著的對(duì)象往一端移動(dòng)，移動(dòng)完成后，直接將另外一端的內(nèi)存清理掉。
因?yàn)閙ark-compact需要移動(dòng)內(nèi)存，因此，垃圾回收主要使用mark-sweep，在內(nèi)存不夠時(shí)，才會(huì)觸發(fā)一次mark-compact。

這三種算法的比較：

Incremental Marking
為了避免出現(xiàn)javaScript應(yīng)用邏輯與垃圾回收器看到不一致的情況，垃圾回收都要將應(yīng)用邏輯停下來(lái)，這種行為會(huì)造成停頓，在新生代垃圾回收過(guò)程中因?yàn)榇婊顚?duì)象比較少，即使停頓基本影響不大。在老生代垃圾回收中，通常存活對(duì)象較多，全堆垃圾回收的標(biāo)記、清除、整理影響較大。
解決辦法：分批次進(jìn)行，拆分成許多小步，每進(jìn)行一小步就讓邏輯運(yùn)行一會(huì)。

v8后續(xù)還引入了lazy sweeping與incremental compaction，同時(shí)還引入了，并行標(biāo)記和并行清理，進(jìn)一步的利用多核性能降低每次停頓的時(shí)間。

內(nèi)存泄漏的實(shí)質(zhì)就是應(yīng)當(dāng)回收的對(duì)象因?yàn)橐馔鉀](méi)有被回收，變成了常駐在老生代中的對(duì)象。
造成內(nèi)存泄漏的主要原因有：緩存、隊(duì)列消費(fèi)不及時(shí)、作用域未釋放。

1）緩存
慎將內(nèi)存當(dāng)做緩存，一旦一個(gè)對(duì)象被當(dāng)做緩存來(lái)使用，那它將會(huì)常駐在老生代中，這將導(dǎo)致垃圾回收在進(jìn)行掃描和整理時(shí)，對(duì)這些對(duì)象做無(wú)用功。
v8內(nèi)存是通過(guò)垃圾回收進(jìn)行處理的，沒(méi)有過(guò)期策略，而真正的緩存是存在過(guò)期策略的。
緩存限制策略：將結(jié)果記錄在數(shù)組中，一旦超過(guò)數(shù)量，就以先進(jìn)先出的方式進(jìn)行淘汰。

2）閉包
閉包是通過(guò)中間函數(shù)進(jìn)行間接訪問(wèn)內(nèi)部變量實(shí)現(xiàn)的一個(gè)功能，一旦變量引用這個(gè)中間函數(shù)，這個(gè)中間函數(shù)將不會(huì)釋放，同時(shí)也會(huì)使原始的作用域不會(huì)得到釋放，作用域中產(chǎn)生的內(nèi)存占用也不會(huì)得到釋放。除非不再有引用，才會(huì)逐步釋放。

參考：構(gòu)建Web應(yīng)用

http是一個(gè)無(wú)狀態(tài)的協(xié)議，現(xiàn)實(shí)中的業(yè)務(wù)卻是需要有狀態(tài)的，否則無(wú)法區(qū)分用戶之間的身份。利用cookie記錄瀏覽器與客戶端之間的狀態(tài)。
cookie的處理分為如下幾步：

服務(wù)器向客戶服務(wù)發(fā)送cookie

瀏覽器將cookie保存

之后每次瀏覽器都會(huì)將cookie發(fā)送給服務(wù)器，服務(wù)器端再進(jìn)行校驗(yàn)

告知客戶端是通過(guò)響應(yīng)報(bào)文實(shí)現(xiàn)的，響應(yīng)的cookie值在set-cookie字段中，它的格式與請(qǐng)求中的格式不太相同，規(guī)范中對(duì)它的定義如下：

Set-Cookie: name=value; Path=/; Expires=Sun, 23-Apr-23 09:01:35 GMT; Domain=.domain.com;

name = value是必選字段，其他為可選字段。

cookie的性能影響

當(dāng)cookie過(guò)多時(shí)，會(huì)導(dǎo)致報(bào)文頭較大，由于大多數(shù)cookie不需要每次都用上，因此，除非cookie過(guò)期，否則會(huì)造成帶寬的浪費(fèi)。

cookie優(yōu)化的建議：

減小cookie的大小，切記不要在路由根節(jié)點(diǎn)設(shè)置cookie，因?yàn)檫@將造成該路徑下的全部請(qǐng)求都會(huì)帶上這些cookie，同時(shí)，靜態(tài)文件的業(yè)務(wù)不關(guān)心狀態(tài)，因此，cookie在靜態(tài)文件服務(wù)下，是沒(méi)有用處，請(qǐng)不要為靜態(tài)服務(wù)設(shè)置cookie。
為靜態(tài)組件使用不同的域名，cookie作用于相同的路由，因此，設(shè)定不同的域名，可以防止cookie被上傳。
減少dns查詢，這個(gè)可以基于瀏覽器的dns緩存來(lái)削弱這個(gè)副作用的影響(換用額外域名需要DNS查詢)。
cookie的不安全性
cookie可以在瀏覽器端，通過(guò)調(diào)用document.cookie來(lái)請(qǐng)求cookie并修改，修改之后，后續(xù)的網(wǎng)絡(luò)請(qǐng)求中就會(huì)攜帶上修改過(guò)后的值。
例如：第三方廣告或者統(tǒng)計(jì)腳本，將cookie和當(dāng)前頁(yè)面綁定，這樣可以標(biāo)識(shí)用戶，得到用戶瀏覽行為。

cookie存在各種問(wèn)題，例如體積大、不安全，為了解決cookie的這些問(wèn)題，session應(yīng)運(yùn)而生，session只保存在服務(wù)器端，客戶端無(wú)法修改，因此，安全性和數(shù)據(jù)傳遞都被保護(hù)。

如何將每個(gè)客戶和服務(wù)器中的數(shù)據(jù)一一對(duì)應(yīng)：

基于cookie來(lái)實(shí)現(xiàn)用戶和數(shù)據(jù)的映射

通過(guò)查詢字符串來(lái)實(shí)現(xiàn)瀏覽器端和服務(wù)器端數(shù)據(jù)的對(duì)應(yīng)。它的原理是檢查請(qǐng)求的查詢字符串，如果沒(méi)值，會(huì)先生成新的帶值的URL。

安全性
session的口令保存在瀏覽器（基于cookie或者查詢字符串的形式都是將口令保存于瀏覽器），因此，會(huì)存在session口令被盜用的情況。當(dāng)web應(yīng)用的用戶十分多，自行設(shè)計(jì)的隨機(jī)算法的口令值就有理論機(jī)會(huì)命中有效的口令值。一旦口令被偽造，服務(wù)器端的數(shù)據(jù)也可能間接被利用，這里提到的session的安全，就主要指如何讓這一口令更加安全。

有一種方法是將這個(gè)口令通過(guò)私鑰加密進(jìn)行簽名，使得偽造的成本較高?？蛻舳吮M管可以偽造口令值，但是由于不知道私鑰值，簽名信息很難偽造。如此，我們只要在響應(yīng)時(shí)將口令和簽名進(jìn)行對(duì)比，如果簽名非法，我們將服務(wù)器端的數(shù)據(jù)立即過(guò)期即可，

將口令進(jìn)行簽名是一個(gè)很好的解決方案，但是如果攻擊者通過(guò)某種方式獲取了一個(gè)真實(shí)的口令和簽名，他就能實(shí)現(xiàn)身份的偽造了，一種方案是將客戶端的某些獨(dú)有信息與口令作為原值，然后簽名，這樣攻擊者一旦不在原始的客戶端上進(jìn)行訪問(wèn)，就會(huì)導(dǎo)致簽名失敗。這些獨(dú)有信息包括用戶IP和用戶代理。

JavaScript的單線程，與它的用途有關(guān)。作為瀏覽器腳本語(yǔ)言，JavaScript的主要用途是與用戶互動(dòng)，以及操作DOM。這決定了它只能是單線程，否則會(huì)帶來(lái)很復(fù)雜的同步問(wèn)題。比如，假定JavaScript同時(shí)有兩個(gè)線程，一個(gè)線程在某個(gè)DOM節(jié)點(diǎn)上添加內(nèi)容，另一個(gè)線程刪除了這個(gè)節(jié)點(diǎn)，這時(shí)瀏覽器應(yīng)該以哪個(gè)線程為準(zhǔn)？
所以，為了避免復(fù)雜性，從一誕生，JavaScript就是單線程，這已經(jīng)成了這門語(yǔ)言的核心特征，將來(lái)也不會(huì)改變。

為了利用多核CPU的計(jì)算能力，HTML5提出Web Worker標(biāo)準(zhǔn)，允許JavaScript腳本創(chuàng)建多個(gè)線程，但是子線程完全受主線程控制，且不得操作DOM。所以，這個(gè)新標(biāo)準(zhǔn)并沒(méi)有改變JavaScript單線程的本質(zhì)。

所有任務(wù)可以分成兩種，一種是同步任務(wù)（synchronous），另一種是異步任務(wù)（asynchronous）。同步任務(wù)指的是，在主線程上排隊(duì)執(zhí)行的任務(wù)，只有前一個(gè)任務(wù)執(zhí)行完畢，才能執(zhí)行后一個(gè)任務(wù)；異步任務(wù)指的是，不進(jìn)入主線程、而進(jìn)入"任務(wù)隊(duì)列"（task queue）的任務(wù)，只有"任務(wù)隊(duì)列"通知主線程，某個(gè)異步任務(wù)可以執(zhí)行了，該任務(wù)才會(huì)進(jìn)入主線程執(zhí)行。

異步執(zhí)行的運(yùn)行機(jī)制如下。（同步執(zhí)行也是如此，因?yàn)樗梢员灰暈闆](méi)有異步任務(wù)的異步執(zhí)行。）

所有同步任務(wù)都在主線程上執(zhí)行，形成一個(gè)執(zhí)行棧（execution context stack）。

主線程之外，還存在一個(gè)"任務(wù)隊(duì)列"（task queue）。只要異步任務(wù)有了運(yùn)行結(jié)果，就在"任務(wù)隊(duì)列"之中放置一個(gè)事件。

一旦"執(zhí)行棧"中的所有同步任務(wù)執(zhí)行完畢，系統(tǒng)就會(huì)讀取"任務(wù)隊(duì)列"，看看里面有哪些事件。那些對(duì)應(yīng)的異步任務(wù)，于是結(jié)束等待狀態(tài)，進(jìn)入執(zhí)行棧，開(kāi)始執(zhí)行。

主線程不斷重復(fù)上面的第三步

js引擎執(zhí)行異步代碼而不用等待，是因有為有 消息隊(duì)列和事件循環(huán)。

消息隊(duì)列：消息隊(duì)列是一個(gè)先進(jìn)先出的隊(duì)列，它里面存放著各種消息。
事件循環(huán)：事件循環(huán)是指主線程重復(fù)從消息隊(duì)列中取消息、執(zhí)行的過(guò)程。

JS中分為兩種任務(wù)類型：macrotask和microtask，在ECMAScript中，microtask稱為jobs，macrotask可稱為task。

宏任務(wù)(macrotask):setTimeout, setInterval, setImmediate, requestAnimationFrame，I/O, UI rendering。

微任務(wù)(microtask):process.nextTick, Promise.then catch finally, MutationObserver，Object.observe 。

在掛起任務(wù)時(shí)，JS 引擎會(huì)將所有任務(wù)按照類別分到這兩個(gè)隊(duì)列中，首先在 macrotask 的隊(duì)列（這個(gè)隊(duì)列也被叫做 task queue）中取出第一個(gè)任務(wù)，執(zhí)行完畢后取出 microtask 隊(duì)列中的所有任務(wù)順序執(zhí)行；之后再取 macrotask 任務(wù)，周而復(fù)始，直至兩個(gè)隊(duì)列的任務(wù)都取完。

宏任務(wù)和微任務(wù)之間的關(guān)系:

事件循環(huán)機(jī)制進(jìn)一步補(bǔ)充

主線程運(yùn)行時(shí)會(huì)產(chǎn)生執(zhí)行棧，棧中的代碼調(diào)用某些api時(shí)，它們會(huì)在事件隊(duì)列中添加各種事件（當(dāng)滿足觸發(fā)條件后，如ajax請(qǐng)求完畢）

而棧中的代碼執(zhí)行完畢，就會(huì)讀取事件隊(duì)列中的事件，去執(zhí)行那些回調(diào)

如此循環(huán)

注意，總是要等待棧中的代碼執(zhí)行完畢后才會(huì)去讀取事件隊(duì)列中的事件

1.http://www.ruanyifeng.com/blo...
2.https://www.jianshu.com/p/f47...
3.實(shí)例

https://blog.csdn.net/mars200...

BFC（Block Formatting Context）叫做“塊級(jí)格式化上下文”。
當(dāng)一個(gè)元素設(shè)置了新的BFC后，就和這個(gè)元素外部的BFC沒(méi)有關(guān)系了，這個(gè)元素只會(huì)去約束自己內(nèi)部的子元素。

1）BFC的布局規(guī)則如下：

內(nèi)部的Box會(huì)在垂直方向，一個(gè)接一個(gè)地放置。

Box垂直方向的距離由margin決定。屬于同一個(gè)BFC的兩個(gè)相鄰Box的margin會(huì)發(fā)生重疊

每個(gè)盒子的左邊界都要緊靠包含容器的左邊界。即使存在浮動(dòng)也是如此。除非這個(gè)元素自己形成了一個(gè)新的BFC。

BFC的區(qū)域不會(huì)與float box重疊。

BFC就是頁(yè)面上的一個(gè)隔離的獨(dú)立容器，容器里面的子元素不會(huì)影響到外面的元素。反之也如此。

計(jì)算BFC的高度時(shí)，浮動(dòng)元素也參與計(jì)算

2）如何產(chǎn)生新的BFC

根元素；

float不為none；

position為absolute，fixed；

display為inline-block，table-cell，table-caption，flex；

overflow不為visible；

3）實(shí)際應(yīng)用

清除浮動(dòng) 例子

margin折疊問(wèn)題

兩側(cè)布局：左邊固定，右邊自適應(yīng)

雙飛翼布局 例子

張?chǎng)涡瘢篊SS深入理解流體特性和BFC特性下多欄自適應(yīng)布局

IFC（Inline Formatting Content）叫做 行內(nèi)格式化上下文。
1）規(guī)則

盒子是水平一個(gè)接一個(gè)的排列，水平的margin，內(nèi)邊距，邊框是可以有的。

垂直方向的對(duì)齊，可能是底部對(duì)齊，頂部對(duì)齊，也可能是基線對(duì)齊（這個(gè)是默認(rèn)的）；ps.這里的盒子應(yīng)該是指的內(nèi)聯(lián)元素的盒子（span，strong等）和匿名內(nèi)聯(lián)盒子(只有文本，沒(méi)有內(nèi)聯(lián)元素包含，自動(dòng)創(chuàng)建的)，他們合稱內(nèi)聯(lián)盒子，一個(gè)或者多個(gè)內(nèi)聯(lián)盒子組成一個(gè)行框，行框的寬度由包含塊和出現(xiàn)的浮動(dòng)決定的。

行框中的內(nèi)聯(lián)盒子的高度小于行框的高度時(shí)，內(nèi)聯(lián)盒子的垂直方向的對(duì)齊方式取決于vertical-align屬性

當(dāng)一個(gè)行框水平不能容納內(nèi)聯(lián)盒子時(shí)，他們將會(huì)在垂直方向上產(chǎn)生多個(gè)行框，他們上下一個(gè)挨著一個(gè)，但是不會(huì)重疊

一般來(lái)說(shuō)，行框的左邊界緊挨著包含容器的左邊界，行框的右邊界緊挨著包含容器的右邊界，（是兩個(gè)邊都緊挨著）。然而，浮動(dòng)盒子可能存在于包含邊框邊界和行框邊界之間；

多個(gè)內(nèi)聯(lián)盒子的寬度小于包含他們的行框時(shí)，他們?cè)谒椒较虻姆植既Q于text-align屬性（默認(rèn)是left）

2）主要影響IFC內(nèi)布局的css： 參考

font-size

line-height

height

vertical-aligin

容器的高度 height = line-height + vertical-align