weixin_43743922的博客

上午刚面一个Java开发岗，深刻体会到自己基础的不扎实，写下此篇，谨记在心。面试官：你平时如何统计一张表的记录数量菜鸡小川：count(1)面试官：那你认为count(1)，count(索引字段)，count(*)之间谁的效率高菜鸡小川：count(1)==count(索引字段)>count(*)--非常干脆的回答了回答完，楞了一下，死去的记忆似乎想唤醒我，but，没给我唤醒不知有多少同学和我一样，认为count(*)肯定是最慢的。以为和select * 一样肯定是要扫所有数据怎么都得慢点。

这篇文章也是自己的一个记录文中的例子，示图都是从上文中提到的文章来的，只为更好的解释浮点数的存储方式，以及论证标题所提出的问题。这个现在应该理解了，0.1，0.2，0.3在二进制下都是无限循环小数啊，即有限的尾数是存不下他的二进制表示的。上面的链接也有解释，这里我进行简单的复述，旨在讲明白这个问题。结束，这样就把这个数存到你的硬盘里了，当然double同理，只是他的尾数范围更大，所以表示的更精确。这个应该也很好理解，double能存的尾数更多，也就是小数点后面数据存的更多，自然也就更精确嘛。

问题就出在Entry上，由于其key指向threadLocal本身，而这个引用是通过弱引用实现的，一旦外部没有了强引用指向threadlocal对象，等下一次GC时，它将会被回收。如果将其改为强引用，那在不使用threadlocal后，连threadLocal对象都回收不了了，因为此时有key强引用指向它。首先，ThreadLocal本身内部就是通过一个ThreadLocalMap来实现的，这种数据结构顾名思义可以理解为一个Map，map的内部有Entry结构，也就是Key，Value来存储键值对。

limit 20 这样的语句。仅仅扫描前30行，select* from table limit 0,10扫描满足条件的10行，返回10行，但当limit 866613，20的时候数据读取就很慢,limit 866613，20的意思扫描满足条件的866633行，扔掉前面的866613行，返回最后的20行，可想而知这时会很慢，如下图，达到37.44秒之久。具体原因：这段sql是走全表扫描，故会从聚簇索引B+树叶子节点中，第一条记录一直遍历到866614这条记录，所以是一条很慢的sql。

这个错误表明在尝试通过 WebSocket 发送文本消息时，WebSocket 连接的状态处于状态，而该状态是不允许调用方法的。这通常发生在。简单说是因为两个不同线程同时调用了sendMessage这个方法，也就是同一时刻向socket写消息冲突了。

这个文件是会缓存数据库结构（补充：看网上帖子，还会缓存数据库），当你在配置文件中开启了tsdb这个选项（默认是开启的），如果你后面变更了表结构，h2数据库对应的缓存是不会更新的，也就是这个文件不会更新，这个时候一般会爆如下异常。这个文件是用于存储canal读取mysql中binlog的偏移量，存储的是json格式，如果服务器突然挂掉，此时这个文件里面的内容可能就会有问题，，重启的时候由于canal会去读取这个文件的内容找到上一次binlog的位置，但是这个文件内容又有问题，此时就会报错。

需要注意的是，虽然 Double-Checked Locking 在一些场景下能够提高性能，但在某些特定情况下可能会引入一些问题，例如指令重排序等，因此在现代 Java 中，更推荐使用基于类加载机制的静态内部类实现的懒汉式单例模式或者直接使用饿汉式单例模式，它们更为简单、安全，并且在大多数情况下性能表现也很好。饿汉式单例模式的优点是实现简单，线程安全，缺点是在应用启动时就创建实例，如果该实例在后续的程序执行中没有被使用，可能会造成资源浪费。饿汉式单例模式在类加载时就创建了实例，因此不存在多线程竞争的问题。

结论：map中调用get时，没有key但是不会报错，会返回null值。