ArrayList.removeAll() vs HashSet.removeAll()

Posted 2023-05-05

参考技术A

这个东西很多人一看就知道原理，哈哈，无奈在下菜菜一枚，记录下以加深印象吧！有不当之处，欢迎大牛批评指正~

其实看标题就知道二者肯定 HashSet更胜一筹，工作中经常遇到 大数据量的 removeAll()操作，以前习惯性用 list，后来数据量大的时候发现效率极低，下面是一些测试和源码分析。

采用 hashSet 代替 arrayList 进行稍大数据量 removeAll 的场景，依据如下：

a、进行了增量测试，测试数据集范围从 1000-->500000 观察 二者的耗时

b、看一下二者 removeAll的操作源码

arrayList: A.removeAll(B)

hashSet: A.removeAll(B)

性能测试 - 响应 vs 延迟 vs 吞吐量 vs 负载 vs 扩展性 vs 压力 vs 健壮性

本文译自Niraj Bhatt 所著 Performance Testing - Response vs. Latency vs. Throughput vs. Load vs. Scalability vs. Stress vs. Stress vs. Robustness. 原文地址：https://nirajrules.wordpress.com/2009/09/17/measuring-performance-response-vs-latency-vs-throughput-vs-load-vs-scalability-vs-stress-vs-robustness/

　　通常我发现当人们谈起性能测试时，总是含混不清及概念混淆的。一些人仅仅把性能测试限制在响应时间，反之，另一些人则试图用性能测试来覆盖测试活动的各个方面。 在这篇博文中，有关这两种看法之间的区别，我将阐述一些自己的观点。在性能测试领域，你会经常听到的一些名词有——响应时间，延迟时间，吞吐量，负载，扩展性，压力，健壮性等等。在下面的文章中，我会试着解释这些名词同时简要介绍如何测量评估他们。

 

　　响应时间（Response Time）——系统在接受到一个请求后，处理这个请求所需要花费的时间。比如你有一个API，你想知道这个API执行一次调用需要花费多少时间，你事实上就是在测量响应时间。 那么到底怎么测量响应时间呢？简单来说，使用一个码表(System.Diagnostics)——在调用之前启动它，在接收到响应后停止。这里的时间间隔将会非常小，所以推荐的做法是循环调用这个API，比如说1000次。 或者如果可能的话在调用时传入负载参数（输入/输出 有KBs/MBs/GBs之分。比如，返回不同长度的用户数组）

 

　　延迟时间（Latency）——最简单的解释是，它是远程调用时的响应时间，例如你想访问的是一个网络服务或一张网页。 除了服务器需要的处理响应的时间外，还需要耽搁一些时间用来将请求从客户端传到服务器。那么说到延迟时间，就是刚刚说到的耽搁的时间。而这对于托管网络服务/网页 的远程数据中心来说，是一个很大的问题。想象一下你从印度访问一个在美国的数据中心。尽管延迟时间是很难被改进缩短的，但是测量它却非常之重要。我们怎么来测量延迟时间? 一些模拟网络条件的工具可以帮助你，这里是其中一个工具。

 

　　吞吐量（Thoughput）——你的应用/系统每秒钟能处理的事务数。一个典型的企业级应用会有很多用户执行各种不同的事务。在系统正式投入使用之前，你应该保证自己的系统达到企业级应用所要求的能力。这种情况下，负载测试（Load Testing）可视为一个解决方案。策略是，挑选一些事务（时常发生的，重要的，密集发生的）看看在SLAs(Service Level Agreement—服务提供商和终端用户之间一个服务级别的合约。用来定义期望从服务提供商处得到的服务等级)允许的时间范围内的通过率是多少。怎么来衡量呢？你通常需要一个高端专业的工具比如Visual Studio Team System（负载测试功能）。 当然了，你你可以使用一些客制的应用/代码来模拟负载。但我的经验是，客制的代码更适合用来测试响应时间（Response Time）。鉴于编写客制化的代码需要的工作量太大，一个好的负载测试工具比如说VSTS可以让你挑选一系列事务，模拟网络延迟，加入用户思考时间（真实用户的反应时间），测试迭代次数等等。我同时强烈建议负载测试使用真实数据以无限接近真实使用场景。

 

　　扩展性（Scalability）—— 扩展性代表在添加了额外的硬件后你的系统将作何反应。系统能够使用新添加的资源来处理增加的负载吗？考虑到未来可能的增长，这一点对你的系统来说极其重要。这里我们有两种选择-向上/垂直扩展（用更好的机器）；或者向外/水平扩展（使用更多的机器）。通常来说后者更受青睐。做水平扩展的一个挑战是，你的设计不能包括一些密切相关（耦合）的服务器，以便负载均衡器可以在不同服务器之间调整负载。通过内置软件或硬件NLB（network load balancer 网络负载均衡器）的负载均衡工具的帮助，你可以衡量系统的扩展性，及保证系统能够承担新增的负载而不出现任何问题。其中一个工具可以监测性能计数器，来检查真实的请求是否已经在服务器间被分派和分享（我计划在未来的博文中谈到NLB）。

 

　　压力测试（Stress Testing）——很多人对压力测试感到困惑，或混淆了它和负载测试。简单的解释是，如果你发现自己连续执行测试超过24小时，你在做的就是压力测试（更精确的说法是在你为了打一个补丁而停下系统之前，系统实际的工作时间/在线时间）。负载测试的动机是衡量你的系统在过载条件下恢复正常的能力。系统是能后恢复到正常，还是彻底崩溃？健壮性，可以视为针对长时间运行且几乎无宕机系统的所做压力测试的一部分。一个简单例子就是内存泄漏。你的系统会在处理峰值负载后释放内存吗？另一个例子是，如果一个磁盘因为持续繁重的I/O(输入输出)负载而失效时会发生什么？你的系统会丢失数据吗？找到并定位这些潜在的风险就是压力测试背后的动机