不要弄混 ACID 中的 C 和 CAP 的 C，前者的重心在于系统整体的一致性, 后者指的是多个副本之间的一致性

###########################################################
# spring @Async
###########################################################
profiler.spring.async.enable=true
# Add custom AsyncTaskExecutor classes. Comma separated list of fully qualified class names. Wildcard not supported.
# Default values
# org.springframework.scheduling.concurrent.ConcurrentTaskExecutor
# org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler
# org.springframework.core.task.SimpleAsyncTaskExecutor
# org.springframework.scheduling.quartz.SimpleThreadPoolTaskExecutor
# org.springframework.core.task.support.TaskExecutorAdapter
# org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor
# org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler
# org.springframework.jca.work.WorkManagerTaskExecutor
# org.springframework.scheduling.commonj.WorkManagerTaskExecutor
profiler.spring.async.executor.class.names=

想要仿照 java 原生 api 你就得把对象映射成共享内存，这样就可以进程通信了，但这个仅限于同一台物理机。要想和机器也没关系，那就只能用中间件了，redis 、zk 好做一些，mq 的话在不考虑事务的情况下也可以使用

才几万条。。。别引入中间件了，直接用个线程池得了

有人工查看时间进行数据捞取的操作就 timestamp 和 datetime，时间要求范围不大的话就 timestamp，注意时间一定要给默认值，不然加索引的索引可能会失效，没有人工查看操作直接 int 性能最佳计算也方便

真实占用没区别，但是在索引创建方面有区别，也会影响总的行长，进而影响行的组织方式，可能会频繁引起页分裂啥的，所以能确定小于 64 就 varchar(64), 后续可能会有改动又不知道多大就直接 varchar(255)，不然从小改到大锁表时间，还有上面说到的页分裂都有可能引发问题

@daozhihun 这只是个近似说法，因为正常情况下使用不到上限而已。而上面的完美散列也只是利用黄金分割率来达到一种勉强的不冲突而已(也没有真实达到)，这个方法的好处只在于计算 hash 的方法极其简单所以性能也非常的好

完美散列是指 hashCode 不冲突，但是桶位的计算一般都是取后几位那么就很有可能冲突，说到底你混淆了桶位和 hashCode

大概率是插件问题，看 system\log 下的 idea.log

查询语句可以带主键(趋势递增才可以), 比如原来的语句是 select * from table limit 1000,10(单页 10 条), 现在给改成
1.select * from table where id >= (select id from table 1imit 1000,1) limit 10
2.Select id from table limit 10000, 10;Select * from table where id in (123,345....);
3.select * from table INNER JOIN (select id from table limit 10000,1) using (id);
4.在代码里记录最后一条的 id, select * from table where id >= ? limit10;
简单来说就是只扫描主键不扫描行记录, 减少一次 B+树中的搜索

@22yune 你这个东西越说越像 B 树了。。。其实我觉得这种东西一定要结合实际业务场景来思考，一定要能解决在某种情况下的技术痛点，在某些场景下比 HashMap 更优更让程序员"偷懒"。 就好比 HashMap 红黑树的树化阈值是 8，是因为 hash 碰撞 8 次的可能性是亿分之六(假设数据遵从泊松分布)，所以它在实际使用中几乎很少树化（更多是为了应对 hash 攻击），但在某些领域要求极其严苛的情况下，你能将这亿分之六都处理好那么你这个东西就有很高的实用价值。

@22yune 你分层是有限的，你的 hashCode 的位数总会被使用完, 而你分层越多，你的容器的容量就会越小。这两个其实还可以接受, 因为正常使用中容量也许不会很大(或者我们就是要创造一种需要结合业务使用量分配层数的容器)，更加致命的是随着容器的层数的增加，扩容带来的开销成倍增长，在理想情况下可以并发进行，但如果遭遇 hash 攻击这种估计瞬间就崩溃了。不过我觉得这个容器还是很有思考和时间意义的，分多少层？每层限量又是多少?我该是扩容下层还是当前层亦或是上层？

https://dev.mysql.com/doc/refman/5.7/en/ 和 https://dev.mysql.com/doc/refman/8.0/en/
算是最全面的介绍了

没听说过静态表动态表这个说法，官方没有这个概念，估计是"以讹传讹"了。官方只有行格式 Row Formats 的概念 https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format.html 默认情况下就是 DYNAMIC 。顺便说一句，mysql 要用就别用 5.7 以前的了，之前版本的性能和特性。嗯，你懂得。

题主可能是想通过无锁化来基于 HashMap 创造一种新的更高性能的并发容器，但我觉得难点其实在于 hash 冲突的问题，一个 hash 碰撞率极低的算法它的实现是极为繁琐的，哪怕你实现了它的性能必然也是很低下的，所以很多人才没有朝这个方向发展，就像都知道 RSA 的安全性更高，实际代码中加密却还大多数是 MD5

把十进制转成二进制就看出规律了, 0100，相当于取第三位, 这个做法比较老但还算常见, linux 的常用权限 755, java 里面对于修饰符的判断都有用到

gc 占用的 cpu 已经很少了，不知道你怎么先入为主得出这个结论的。顺便吐槽下 gc 日志不给，只给个线程的快照有什么用

条件允许直接上 arthas，把你整个函数切成片分析

jstack 看线程，打印什么的不靠谱，不一定是业务线程。我这就遇到过很多其他处理阻塞主程的操作, 比如日志输出（输出流重定向到 kafka ）因为用的第三方库不够健壮一步发送 kafka 消息阻塞了业务线程。