很好，扎扎实实的学习

hashCode = count 值，元素是相同的，只不过存储位置不同。
因为 first(count=3) 元素存储在了 hashCode 值为 3 的地方，已经存进去了，即使修改了 count(修改为-3) 值，使得元素的 hashCode 值也改变为-3，但是存储位置没变。
所以，c1.contains(new R(-3)) 返回 false，因为 new R(-3) 去 hashSet 中寻找的是 hashCode 为-3 的存储位置，但是已经被删除了，所以返回 false

哇，这个质量够差的了

嗯嗯，是，主要是地段

我也是刚学习，具体项目还没应用过，欢迎大家多多指导

飞哥，你不是买了吗？

最后买了哪里啊

刚需，首套，结婚

恒温要进军人工智能了

把你这里的配置发一下看看

试试第二个设置，可以吗？

执行之后没反应？看看 jmeter 的日志

可以敲代码的话，用https://testerhome.com/opensource_projects/avatar吧
jmeter 的不够灵活

分两方面去验证这个问题吧：
1、验证你的业务性能，可以用多台 jmeter 或者其他测试工具去做；
2、验证 jmeter 的压力性能，可以在验证了你的服务能力后，用不同的压力工具去做同类对比，然后再得出结论

你是外网压测的，还是内网压测的？

嗯嗯

不是说服别人，我的意思是，既然您已经 5、6 年没有接触过一线的技术了，其实没必要在具体的问题这里浪费时间。
您这个级别的，可以给更多的方向性指导，相信您对于质量体系和质量管理这块很有建树

从题主的答案和推理逻辑，以及你的 “这个服气” 里面看出来的，并没有了解到问题的本质，不了了之的 “服气”

让我想起来最近面试，碰到的一个研发部门总监，问我 loadrunner 的参数化怎么做的，我还心想问这个干什么，这不是很基本的问题嘛
后来才知道，他的使用经验在 2000 年的时候。

公司面试流程还是很重要的，如果脱离太久，就不要问那种问题了

你碰到的这个问题，具体分析，如果是你服务器端的连接数有限，导致的 QPS 上不去，你就是再多的并发用户，也进不去真正的队列
当你的连接数够大的时候，你的并发用户才能真正的进行排队，然后对你的服务器才有真实的压力

哥，从你回答的 jmeter 和 loadrunner 这两个问题来看，你是不是离开一线时间太长了？？？

从这里来看，你是想测试业务的性能拐点吗？
如果你想测试性能拐点，首先要保证你的压测服务器本身不是瓶颈，确保真的发出了你所设置的线程或者并发

jmeter 这个锅不背