过几年等头发掉光 就不迷茫了

大家好，我是鱼

既然是只处理第一个 string，没看懂外面一圈 for 是拿来干嘛的

刷 LeetCode
读 SICP

U2718Q

Sorry 没看到说也测过多线程

你一个 thread 跑成这样够好了啊亲

@mzdblsw8 三本被砍掉以后，现在的二本很多是以前的三本甚至专科

编译器是 NDK 自带的，现在应该只有 clang。gcc 我记得是前两年 NDK 就 deprecated 掉了。

2.6GHz 主频的 7 代 i5，MIPS(每秒执行百万条指令数)大约是 53K。

0 循环到 max int，循环次数是 2,147,483,647，假设每个循环只执行三条指令，大约是 6K 个百万条指令。

也就是说，一个什么也不做的从 0 到 max int 的循环，在 7 代 i5 上，大约应该花 0.1 秒这么个量级的时间。我们就放宽一点，给它再快个 10 倍，大约应该花 10ms 这个量级的时间。今天应该还没有一款 CPU 的单核 IPC 能达到 10 倍 i5 的水平。

你猜猜看你的第二个循环为啥 1ms 就跑完了？

因为 JIT 在跑了前面的几百或者几千次循环以后开始介入编译，发现你的 test()很小，应该内联进循环，然后就内联了。内联以后一看原来整个循环也啥也没做，就把循环也优化掉了。

而第一个循环，反射是实打实没法优化掉的。

这个故事告诉我们，microbenchmark 通常没什么鸟用。如果一定要做 microbenchmark，请至少正确使用 JMH，在代码里通过 JMH 的 API 强制添加副作用，避免不希望的优化发生。

另外，即使反射比普通调用真的慢一千倍，实际到你的产品里很可能也只有不到 1%的差距。打个比方，如果你的方法本身要花 1 秒，反射花 1 毫秒，直接调用花 1 微秒，把你的方法调用 1 万次，区别也只有千分之一。

@wolfie tom's hardware 的评测显示，浏览器内视频全屏播放性能很糟糕，估计是驱动问题

4 x A72，TF 卡 IO 提高接近一倍，真 USB 3 和千兆网卡，4GB 内存…… shut up and take my money

@shikimoon 广义的 contention 就是两个或者更多线程竞争同一个资源。对 synchronized 这样的临界区来说，就是有一个以上的线程都试图进入同一个 synchronized 修饰的 block。

@zazalu 说歉意言重了，大家都是参加讨论互相学习，我不是搞高并发的专家，也很业余的。而且我觉得你总结得比我好多了。

另外我举例子的那个网页，之前我没有细看他的代码和结论，需要道歉的是我 XD
其实他本身的方法和结论有很大的问题。像 RWLock，本来就是为多读少写的情况下提高读吞吐量而存在，他的 benchmark 反而显示多读少写的情况下 RWLock 最慢，是因为他统计的是读写线程全部完成以后的最大耗时，而不是读 /写各自的吞吐量。在多读少写的情况下，写线程会因为大量读锁而等待，所以按他的测量方式反而会大幅拖慢总运行时间。

@arrow2015 不不，十多年前做 J2ME VM 的

前 JVM 开发者，建议谨慎应用你的结论 :)

简单说 synchronized 并不一定就是悲观锁，JVM 会先尝试基于 CAS 的瘦锁，发现有 contention 再升级为重量级的悲观锁。

实际用哪种锁，取决于你并发的规模和读 /写比例。多数情况下，因为 synchronized 的自适应性，其实综合表现更好。不然为什么 Java 8 的 concurrenthashmap 仍然用 synchronized 来锁 slot。

你可以看下 https://blog.overops.com/java-8-stampedlocks-vs-readwritelocks-and-synchronized/，你的 CAS 实现大致对应里面的 StampedLock 版本。然后他里面的 optimistic 版本是 fail fast 的，其实没有比较意义。

另外要做 Java 的 microbenchmark，必须要考虑 JIT 的介入，还是得用 JMH，自己写个大循环加 current time millis 远远不够。

@bengcaca v2 还是有靠谱的回答的👍

这就是互联网基础设施建设 /运营能力的差异啊。世界上带宽最贵的地方就是我国和澳洲。

Druid 了解一下