长发哥在书中也说到了：在服务端检查令牌可能看起来有点复杂，但是这其实是推荐的正确的做法：系统服务不能假定所有的客户端都表现的符合预期。从安全角度讲，服务端必须防范这种来自客户端的滥用。

Roots确定后，对象图就已经确定了。SATB扫描的时候基于已经确定的对象图（快照版的对象图）扫描，也就是说扫描过程中上面的快照图的引用关系是不会发生变化的，但是真实的对象图是会发生变化的。

http://hg.openjdk.java.net/jdk/jdk/file/fa2f93f99dbc/src/hotspot/share/gc/g1/heapRegionBounds.hpp

其实我也不是很有资格给你们修改简历，也不是一个技术很牛逼的人，只是把我知道的分享出来了而已，不仅能让我巩固知识，还是倒逼我进行知识输入，在此之外还能对你有一点点帮助，那就是我文章的全部价值所在。

这个2013年（第二版出版那年）挖下的坑，在2016年10月1日，就被R大在知乎上给填上了。R大的这个回答也被作者周志明写在了2019年底出版的《深入理解Java虚拟机（第三版）》的注脚里面：

需要注意的是，十种实现方法其中只有failover、failfast、failsafe、failback、forking、broadcast这6种才属于集群容错的范畴。另外的实现均有其他的应用场景。

本书中Bob大叔提倡”写代码犹如写文章“，又说到“大师级程序员把系统当故事来讲，而不是当做程序来写”，对此观点我印象深刻！在此之前我从未听说过可以把代码当成故事、文章来写，Bob大叔太有才了！

高三最后冲刺的那一段时间，我开始有点浮躁不安，为了让自己静下来，我把一个生物资料总复习从头到尾，包括图表，一字不漏的抄了一次。在某一页，我还写下了一句话，也是这句话，陪我度过了高三最后的一段时间：

这些任务存储在阻塞队列中，只有当thead调用waitAndDrain()方法时才会真正执行。简单来说就是，执行task的thead与调用waitAndDrain()方法的thead完全相同。

简而言之：系统运行中，如果有错误发生，那么系统立即结束，这种设计就是快速失败。系统运行中，如果有错误发生，系统不会停止运行，它忽略错误（但是会有地方记录下来），继续运行，这种设计就是失败安全。

修复方法也是特别简单：把获取identityHashCode的方法从System.identityHashCode(invokers)修改为invokers.hashCode()即可。如下图所示：

我走的那天，去研发部找领导签字，研发部60余人，每一个人我都认识，每一个人我都一一告别，握手拥抱。办完离职后，我所在团队的小伙伴们都在会议室里开会，我说：我走了啊，谢谢各位这几年的陪伴，大家加油啊。

4.01第17.13.4节，其中明确指出：当content-type为application/x-www-form-urlencoded时，对names和vaules进行转义，空格用'+'代替。

再说说双缝干涉实验，太神奇了，到底是左边还是右边？到底是波还是粒子？太疯狂了，真的颠覆了我对世界的认知。最后"不得已"引入了意识的概念，不看它，它是波，看它，它是粒子。因为它坍缩了。

示例代码还是沿用之前文章中的Demo，不了解的可以查看《一文讲透Dubbo负载均衡之最小活跃数算法》，本文分别在20881、20882、20883端口启动三个服务，各自的权重分别为1,2,3。

如上图所示，假设0,1,2号服务器都存储的有用户信息，那么当我们需要获取某用户信息时，因为我们不知道该用户信息存放在哪一台服务器中，所以需要分别查询0,1,2号服务器。这样获取数据的效率是极低的。

本小节主要介绍了RpcStatus类中的active字段在最小活跃数算法中所承担的作用，以及其什么时候发生变化。让读者明白为什么需要在customer端配置ActiveLimitFilter拦截器。

如果面试官问的是为什么ConcurrentHashMap的value不能为null？这样的面试题还是有意义的，因为你还能和他掰扯掰扯二义性。说明你对ConcurrentHashMap有一定的思考。

后来我把这个问题分享在群里之后，群里一个朋友也给我分享了一篇文章，肥朝大佬写的《还有这种操作?浅析为什么要看源码》。文中给出了另一种解决方案，有理有据，简明扼要，是一篇很好的文章，大家可以看看。

微信规定关注人数过500之后，就可以开通流量主了。所以在第七篇《面试了15位来自985/211高校的2020届研究生之后的思考》后我都开启了流量主功能。截止目前，我所有的流量主收入是214.89元。

首先，我们的需求是为了演示问题方便，但是我们的前提是得保证实验对象的一致性，换句话说就是：我们自定义的ArrayList需要和JDK的ArrayList的实现，一模一样，只是换个名称而已。

简化部署:当有新功能来临时，如果经过需求拆分后，发现只需要修改支付服务即可。那我们只需要修改并部署支付服务即可。如果不是微服务架构，你得整个项目重新部署，包括没有改动的部分，这是我们不希望看见的。

正是因为大多数人都知道并且读过这个规范(毕竟是业界权威)。所以呼声最高的答案是【会发生ConcurrentModifyException】。因为他们知道阿里java开发手册里面是强制要求：

如果按照上述方式来发布states，就会出现问题，因为任何调用者都能修改这个数组的内容。在程序清单3-6中，数组states已经"逸出"了它所在的作用域，因为这个本应该是私有的变量已经被发布了。

大家关注我的时候，我也说了：在这里我会分享一些技术相关的东西，主攻java方向，用匠心敲代码，对每一行代码负责。偶尔也会荒腔走板的聊一聊生活，写一写书评，影评。愿你我共同进步。

在这里我会分享一些java技术相关的知识，用匠心敲代码，对每一行代码负责。偶尔也会荒腔走板的聊一聊生活，写一写书评、影评。感谢你的关注，愿你我共同进步。

而且在这个四处宣讲高并发,低延时的时代，你居然让你的用户等待了宝贵的100ms。有可能别人比你快100ms，就抢走了大批用户。你说，你是何居心？是不是敌人派来的卧底？方案二

我能进入决赛，有一部分原因是老师暗中相助，老师相助的原因在第二个转折点里面会说明。有一部分原因是我的作品也没有我自己想象的那么差，从布局到设计，从按钮到链接，每一个都是我自己想出来的，全部都是原创。

晚上如约接到了电话。我们直奔主题，在你来我往中进行了友好的技术交流。具体的面试过程就不详述了，后面有机会整理一份面试分享。整个面试过程中，有这么一道题给我留下了深刻的印象:

2.Service的saveMian方法里面直接调用了这个Service里面某个有@Transactional注解的方法，假如是saveSub（直接调用:saveSub或者this.saveSub）

看到这个地方的时候我曾经走了一点弯路，甚至走上了歧途，一度质疑Dubbo的这个地方的源码是有问题的，毕竟我们搞技术的，就是一个大胆假设，小心求证吧。所以我给Dubbo提了一个issus.如下: