javascript array push，javascript array
大家好,今天小编来为大家解答以下的问题，关于javascript array push，javascript array这个很多人还不知道，现在让我们一起来看看吧！
JS 数组的 push 与 concat 区别
1、功能不同
push()方法可向数组的末尾添加一个或多个元素，并返回新的长度。
concat()()方法用于连接两个或多个数组，该方法不会改变现有的数组，而仅仅会返回被连接数组的一个副本。
2、函数不同
push()：
vara=[1,2,3,4];
a.push(5);//a现在是1,2,3,4,5
concat()：
vara=[1,2,3,4];
varb=[5,6];
varc=a.concat(b);//a,b数组都不变，c变成了1,2,3,4,5,6
扩展资料：
push是一个汇编术语，实现压入操作的指令是PUSH指令，实现弹出操作的指令是POP指令。
push()说明
push()方法可把它的参数顺序添加到 arrayObject的尾部。它直接修改 arrayObject，而不是创建一个新的数组。push()方法和 pop()方法使用数组提供的先进后出栈的功能。
concat()返回值
返回一个新的数组。该数组是通过把所有 arrayX参数添加到 arrayObject中生成的。如果要进行 concat()操作的参数是数组，那么添加的是数组中的元素，而不是数组。
例子
把 concat()中的参数连接到数组 a中：
<script type="text/javascript">
var a= [1,2,3];
document.write(a.concat(4,5));
</script>
输出：1,2,3,4,5
参考资料来源：百度百科-push（汇编术语）
Javascript中数组的常用方法有哪些
concat()连接两个或更多的数组，并返回结果。
join()把数组的所有元素放入一个字符串。元素通过指定的分隔符进行分隔。
pop()删除并返回数组的最后一个元素
push()向数组的末尾添加一个或更多元素，并返回新的长度。
reverse()颠倒数组中元素的顺序。
shift()删除并返回数组的第一个元素
slice()从某个已有的数组返回选定的元素
sort()对数组的元素进行排序
splice()删除元素，并向数组添加新元素。
toSource()返回该对象的源代码
toString()把数组转换为字符串，并返回结果。
toLocaleString()把数组转换为本地数组，并返回结果。
unshift()向数组的开头添加一个或更多元素，并返回新的长度。
valueOf()返回数组对象的原始值
如何避免JavaScript的内存泄露
使用 Chrome发现内存泄露
实质上有两种类型的泄露：周期性的内存增长导致的泄露，以及偶现的内存泄露。显而易见，周期性的内存泄露很容易发现；偶现的泄露比较棘手，一般容易被忽视，偶尔发生一次可能被认为是优化问题，周期性发生的则被认为是必须解决的 bug。
以 Chrome文档中的代码为例：
var x= []; function createSomeNodes(){ var div, i= 100, frag= document.createDocumentFragment(); for(;i> 0; i--){ div= document.createElement("div"); div.appendChild(document.createTextNode(i+"-"+ new Date().toTimeString())); frag.appendChild(div);} document.getElementById("nodes").appendChild(frag);} function grow(){ x.push(new Array(1000000).join('x')); createSomeNodes(); setTimeout(grow,1000);}
当 grow执行的时候，开始创建 div节点并插入到 DOM中，并且给全局变量分配一个巨大的数组。通过以上提到的工具可以检测到内存稳定上升。
找出周期性增长的内存
timeline标签擅长做这些。在 Chrome中打开例子，打开 Dev Tools，切换到 timeline，勾选 memory并点击记录按钮，然后点击页面上的 The Button按钮。过一阵停止记录看结果：
两种迹象显示出现了内存泄露，图中的 Nodes（绿线）和 JS heap（蓝线）。Nodes稳定增长，并未下降，这是个显著的信号。
JS heap的内存占用也是稳定增长。由于垃圾收集器的影响，并不那么容易发现。图中显示内存占用忽涨忽跌，实际上每一次下跌之后，JS heap的大小都比原先大了。换言之，尽管垃圾收集器不断的收集内存，内存还是周期性的泄露了。
确定存在内存泄露之后，我们找找根源所在。
保存两个快照
切换到 Chrome Dev Tools的 profiles标签，刷新页面，等页面刷新完成之后，点击 Take Heap Snapshot保存快照作为基准。而后再次点击 The Button按钮，等数秒以后，保存第二个快照。
筛选菜单选择 Summary，右侧选择 Objects allocated between Snapshot 1 and Snapshot 2，或者筛选菜单选择 Comparison，然后可以看到一个对比列表。
此例很容易找到内存泄露，看下(string)的 Size Delta Constructor，8MB，58个新对象。新对象被分配，但是没有释放，占用了8MB。
如果展开(string) Constructor，会看到许多单独的内存分配。选择某一个单独的分配，下面的 retainers会吸引我们的注意。
我们已选择的分配是数组的一部分，数组关联到 window对象的 x变量。这里展示了从巨大对象到无法回收的 root（window）的完整路径。我们已经找到了潜在的泄露以及它的出处。
我们的例子还算简单，只泄露了少量的 DOM节点，利用以上提到的快照很容易发现。对于更大型的网站，Chrome还提供了 Record Heap Allocations功能。
Record heap allocations找内存泄露
回到 Chrome Dev Tools的 profiles标签，点击 Record Heap Allocations。工具运行的时候，注意顶部的蓝条，代表了内存分配，每一秒有大量的内存分配。运行几秒以后停止。
上图中可以看到工具的杀手锏：选择某一条时间线，可以看到这个时间段的内存分配情况。尽可能选择接近峰值的时间线，下面的列表仅显示了三种 constructor：其一是泄露最严重的（string），下一个是关联的 DOM分配，最后一个是 Text constructor（DOM叶子节点包含的文本）。
从列表中选择一个 HTMLDivElement constructor，然后选择 Allocation stack。
现在知道元素被分配到哪里了吧（grow-> createSomeNodes），仔细观察一下图中的时间线，发现 HTMLDivElement constructor调用了许多次，意味着内存一直被占用，无法被 GC回收，我们知道了这些对象被分配的确切位置（createSomeNodes）。回到代码本身，探讨下如何修复内存泄露吧。
另一个有用的特性
在 heap allocations的结果区域，选择 Allocation。
这个视图呈现了内存分配相关的功能列表，我们立刻看到了 grow和 createSomeNodes。当选择 grow时，看看相关的 object constructor，清楚地看到(string), HTMLDivElement和 Text泄露了。
结合以上提到的工具，可以轻松找到内存泄露。
OK，本文到此结束，希望对大家有所帮助。