这个问题我在网上查原因说是由于Zookeeper压力过大，表变成只读状态，导致ClickHouse插入数据失败。写入数据频率过高。Zookeeper中的集群节点挂掉。而我们项目出现这个问题的原因是第一个：写入数据频率过高。但是在网上搜资料的过程中，我又发现了另外一个问题：我们项目用了JDBC驱动，但ClickHouse官方并不推荐。。证实了官网确实不建议使用驱动：而应该改成驱动，并且推荐使用0.3.2以上的版本：于是，后面几天开始了ClickHouse的JDBC驱动升级之旅。

前言最近review别人代码的时候，发现有个同事，在某个业务场景下，使用Objects.equals方法判断两个值相等时，返回了跟预期不一致的结果，引起了我的兴趣。原本以为判断结果会返回true的，但实际上返回了false。记得很早之前，我使用Objects.equals方法也踩过类似的坑，所以有必要把这个问题记录下来，分享给大家。到底怎么回事呢？1. 案发现场假设现在有这样一个需求：判断当前登录的用户，如果是我们指定的系统管理员，则发送一封邮件。系统管理员没有特殊的字段标识，他的用户id=88

前言对于从事java开发工作的同学来说，spring的事务肯定再熟悉不过了。在某些业务场景下，如果一个请求中，需要同时写入多张表的数据。为了保证操作的原子性（要么同时成功，要么同时失败），避免数据不一致的情况，我们一般都会用到spring事务。确实，spring事务用起来贼爽，就用一个简单的注解：@Transactional，就能轻松搞定事务。我猜大部分小伙伴也是这样用的，而且一直用一直爽。但如果你使用不当，它也会坑你于无形。今天我们就一起聊聊，事务失效的一些场景，说不定你已经中招了。不信，让我们

前言代码死循环这个话题，个人觉得还是挺有趣的。因为只要是开发人员，必定会踩过这个坑。如果真的没踩过，只能说明你代码写少了，或者是真正的大神。尽管很多时候，我们在极力避免这类问题的发生，但很多时候，死循环却悄咪咪的来了，坑你于无形之中。我敢保证，如果你读完这篇文章，一定会对代码死循环有一些新的认识，学到一些非常实用的经验，少走一些弯路。死循环的危害我们先来一起了解一下，代码死循环到底有哪些危害？程序进入假死状态， 当某个请求导致的死循环，该请求将会在很大的一段时间内，都无法获取接口的返回，程序好