内容

1.内存泄漏与垃圾回收2.cookie和session3.单线程原理4.上下左右居中的几种实现。5.BFC和IFC模型。

一、垃圾回收与内存泄漏

参考：内存控制

1.垃圾回收

v8的垃圾回收策略主要基于分代式垃圾回收机制。按照对象的存活时间将内存的垃圾回收进行不同的分代，然后，分别对不同的分代的内存再进行高效的垃圾回收算法。在V8中，主要将内存分为新生代和老生代两代。新内存中的对象存活时间短，老内存中的对象存活时间长或常驻内存对象。

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

新生代中的对象主要通过scavenge算法进行垃圾回收，其主要是采用cheney算法进行具体处理。

cheney算法采用一种复制方式的垃圾回收算法，将堆内存一分为二，只有一部分空间被使用称为From空间，另一个处于闲置称为To空间。当进行分配对象的时候先在from空间分配，当进行垃圾回收时，会检查from空间中的存活对象，将这些存活对象复制到to空间中,复制完成后From和to空间角色互换，清空to空间，在垃圾回收过程中就是通过将存活对象在两个空间中进行复制。

• 缺点： 只能使用一半的内存
• 优点： 只复制存活的对象，对于生命周期短的场景存活对象只占小部分，所以时间效率高

当一个对象经过多次复制依然存活时，就会被认为是生命周期较长的对象，会被移入老生代内存中。

对于移入老生代内存有两个条件：

• 对象已经经过新生代内存回收机制的回收依然存活
• 复制到To空间的对象超过25%（为什么是25%？这个To空间接下来会成为From空间并接受内存分配，如果占比过高影响后续分配）

2）老内存垃圾回收算法Mark-Sweep & Mark-Compact

老内存中，大多是不死的老对象，用scavenge算法又费力，又占用空间，因此，采用了新的内存垃圾回收算法：Mark-Sweep & Mark-Compact。

Mark-Sweep 标记清扫

mark-sweep分为标记和清除两个阶段，mark阶段会遍历堆，然后标记处活着的对象，sweep阶段会清除没有被标记的对象。mark-sweep只清理没有标记的对象，在老内存中，死了的对象占比较少，这也是这个算法高效的原因。

mark-sweep的问题在于，每次sweep后，会存在内存碎片，这些不连续的内存碎片会占有大量空间，因此，下一次复制大对象时，将会发现空间不够，因而再次触发垃圾回收，这个回收是不必要的，也浪费了cpu。为了解决这个问题，增加了mark-compact算法。

mark-compact 标记整理和压缩
mark-compact在整理过程中，将活着的对象往一端移动，移动完成后，直接将另外一端的内存清理掉。
因为mark-compact需要移动内存，因此，垃圾回收主要使用mark-sweep，在内存不够时，才会触发一次mark-compact。

这三种算法的比较：

Incremental Marking
为了避免出现javaScript应用逻辑与垃圾回收器看到不一致的情况，垃圾回收都要将应用逻辑停下来，这种行为会造成停顿，在新生代垃圾回收过程中因为存活对象比较少，即使停顿基本影响不大。在老生代垃圾回收中，通常存活对象较多，全堆垃圾回收的标记、清除、整理影响较大。
解决办法：分批次进行，拆分成许多小步，每进行一小步就让逻辑运行一会。

v8后续还引入了lazy sweeping与incremental compaction，同时还引入了，并行标记和并行清理，进一步的利用多核性能降低每次停顿的时间。

2.内存泄漏

内存泄漏的实质就是应当回收的对象因为意外没有被回收，变成了常驻在老生代中的对象。
造成内存泄漏的主要原因有：缓存、队列消费不及时、作用域未释放。

1）缓存
慎将内存当做缓存，一旦一个对象被当做缓存来使用，那它将会常驻在老生代中，这将导致垃圾回收在进行扫描和整理时，对这些对象做无用功。
v8内存是通过垃圾回收进行处理的，没有过期策略，而真正的缓存是存在过期策略的。
缓存限制策略：将结果记录在数组中，一旦超过数量，就以先进先出的方式进行淘汰。

2）闭包
闭包是通过中间函数进行间接访问内部变量实现的一个功能，一旦变量引用这个中间函数，这个中间函数将不会释放，同时也会使原始的作用域不会得到释放，作用域中产生的内存占用也不会得到释放。除非不再有引用，才会逐步释放。

二、cookie和session

参考：构建Web应用

1.cookie

http是一个无状态的协议，现实中的业务却是需要有状态的，否则无法区分用户之间的身份。利用cookie记录浏览器与客户端之间的状态。
cookie的处理分为如下几步：

• 服务器向客户服务发送cookie
• 浏览器将cookie保存
• 之后每次浏览器都会将cookie发送给服务器，服务器端再进行校验

告知客户端是通过响应报文实现的，响应的cookie值在set-cookie字段中，它的格式与请求中的格式不太相同，规范中对它的定义如下：

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

name = value是必选字段，其他为可选字段。

cookie的性能影响

当cookie过多时，会导致报文头较大，由于大多数cookie不需要每次都用上，因此，除非cookie过期，否则会造成带宽的浪费。

cookie优化的建议：

减小cookie的大小，切记不要在路由根节点设置cookie，因为这将造成该路径下的全部请求都会带上这些cookie，同时，静态文件的业务不关心状态，因此，cookie在静态文件服务下，是没有用处，请不要为静态服务设置cookie。
为静态组件使用不同的域名，cookie作用于相同的路由，因此，设定不同的域名，可以防止cookie被上传。
减少dns查询，这个可以基于浏览器的dns缓存来削弱这个副作用的影响(换用额外域名需要DNS查询)。
cookie的不安全性
cookie可以在浏览器端，通过调用document.cookie来请求cookie并修改，修改之后，后续的网络请求中就会携带上修改过后的值。
例如：第三方广告或者统计脚本，将cookie和当前页面绑定，这样可以标识用户，得到用户浏览行为。

2.session

cookie存在各种问题，例如体积大、不安全，为了解决cookie的这些问题，session应运而生，session只保存在服务器端，客户端无法修改，因此，安全性和数据传递都被保护。

如何将每个客户和服务器中的数据一一对应：

• 基于cookie来实现用户和数据的映射
• 通过查询字符串来实现浏览器端和服务器端数据的对应。它的原理是检查请求的查询字符串，如果没值，会先生成新的带值的URL。

安全性
session的口令保存在浏览器（基于cookie或者查询字符串的形式都是将口令保存于浏览器），因此，会存在session口令被盗用的情况。当web应用的用户十分多，自行设计的随机算法的口令值就有理论机会命中有效的口令值。一旦口令被伪造，服务器端的数据也可能间接被利用，这里提到的session的安全，就主要指如何让这一口令更加安全。

有一种方法是将这个口令通过私钥加密进行签名，使得伪造的成本较高。客户端尽管可以伪造口令值，但是由于不知道私钥值，签名信息很难伪造。如此，我们只要在响应时将口令和签名进行对比，如果签名非法，我们将服务器端的数据立即过期即可，

将口令进行签名是一个很好的解决方案，但是如果攻击者通过某种方式获取了一个真实的口令和签名，他就能实现身份的伪造了，一种方案是将客户端的某些独有信息与口令作为原值，然后签名，这样攻击者一旦不在原始的客户端上进行访问，就会导致签名失败。这些独有信息包括用户IP和用户代理。

三、单线程原理