如果在秒杀、抢购、整点打卡签到、微博热点事件这些业务场景用令牌桶的话，会出现大量用户访问出错，因为请求被直接丢弃了

令牌桶的保护主要是丢弃请求（即使系统还能处理，只要超过指定的速率就丢弃，除非此时动态提高速率

// a 走一步，如果走到根节点，转到 q 节点

算法推荐，对用户是极度友好的。因为，这个机制，会让内容无限地“卷”起来，只有最好的内容，才能在永不停止的投票中胜出，获得触达用户的权力。而且，就算你的上一条内容胜出了，触达了海量的用户，也不意味着你的下一条内容一样能火。因为胜出的，是你的某一条内容，不是你。你的下一条内容，还要重新参加海选。所以，触达用户，是一个无限竞赛。

Expose

glance

reveal

cluttered

To that end we would like to disable, deprecate, and eventually remove support for biased locking.

impediment

the cost of executing cheap lock owner checks plus an occasional expensive revocation is still lower than the cost of executing the eluded compare-and-swap atomic instructions.

Many applications that benefited from biased locking are older, legacy applications that use the early Java collection APIs, which synchronize on every access (e.g., Hashtable and Vector)

Biased locking comes with the cost of requiring an expensive revocation operation in case of contention.