前言
我们都知道 chrome 的单个标签内存占用都是有限制的，平均也就2~4G，32位的只会更少，并且这很多情况下只是理想状态，当桌面应用多开的时候，chrome 单个页签的大小更是会大幅度缩水，那么我们怎样解决chrome的内存分配上限呢
为什么
疑问：为何要管这个内存分配上限问题？
答：内存不足时，无论是操作系统还是浏览器都会有一些内存交换或者释放内存的方式，无论是哪一个短时间内都是极度耗费性能的，尤其是单纯的内存占用高的问题，频繁的内存交换，这个只会造成更严重的页面严重卡顿，甚至无响应，也就是说到底内存问题还是会再转化为标注你的性能优化问题
一般场景
解决单页签内存分配上限时，我们首先要看问题在哪里，一般会有下面几种场景：
- 页面递归死循环，堆栈溢出，这个属于重大bug，需要及时解决，不多解释
- 页面出现了循环引用内存泄漏，导致内存没能及时释放，出现内存占用过高，此时我们要想尽办法解决内存泄漏问题，当然这个问题算是中等问题，因为还有垃圾回收，只要不是全局引用的一般都会随着页面资源的释放释放，或者内存不足时统一释放回收
- 页面出现了海量数据需要展示的数据，但是又无可奈何的时候，只能想尽办法来避免占用过高，常见的：echarts图标大量数据，直播巨量弹幕等
一些解决方案
递归死循环
对于递归死循环的问题，只能说，靠实力或者队友解决此bug，不应该出现
内存泄漏
当页面出现内存泄漏的时候，前端一般出现在闭包场景，或者强引用场景，出现了类似的循环引用问题，导致内存无法释放或者无法及时释放，累计起来也是一个不小的数字
对于常规页面内的循环引用，一般会随着页面的释放，那片内存空间会成为无主之物，会成为垃圾回收的养料，一般不管
主要是涉及到模块或者全局场景，这类大对象的强引用问题需要注意，如果不及时释放持有，则可能会长期持有，导致内存居高不不下，成为压死骆驼的最后一根稻草
海量数据问题
对于海量的数据问题，常见的就是大屏echart 之类的表格折线图等数据了，这类数据可以通过一些算法，优化尽量减少数据、分段渲染，甚至更改展示区间逻辑，这样内存高占用以及非高占用的卡顿问题能够改善
对于海量数据，还有另外一种情况，就是需要展示海量内容很多，单独一个页面无论怎么处理都是非常麻烦的，此时可以将该页面展示一个概览数据，当需要看详情的时候，直接跳转到另外一个浏览器标签，这样新的把标签的内存占用情况会明显改善，对于新标签页仍然占用过高的情况，仍然使用之前的数据分段减少数据等手段解决
最后
从chrome的内存分配上限，到转化为实际的性能瓶颈优化，到bug修复，到内存泄漏问题，再到海量数据优化，再到页面分布改善标签跳转等
解决问题的思路总是随着我们的疑问，一步一步向外延伸，问题和解决的方案上面也只是其中一部分，分析问题实际上也是我们进步的一环
本篇文章也就介绍到这里了，下次见😄