提前退休的java猿

前言 多线程和幽灵代码 这次介绍的是第四章和第五章的内容，因为这两章的内容比较少我就把他合到一起了 ，这两章有些内容比较基础吧. 比如第四章写了 如何加锁，如果正确的使用synchronized，以及

内存泄露分析和堆内存设置 这一章节主要介绍了垃圾回收器的基础知识，然后再举出内存泄漏的案例让我们能够轻松的理解内存泄露的原理。 接着又介绍了内存泄露的症状以及定位和分析的手段，然后就是介绍了内存

第二章的主题是通过堆栈分析性能瓶颈，但是介绍通过的堆栈分析的性能瓶颈的内容其实不多。更多的是介绍性能瓶颈相关的基本原理，其次是分享了一些造成性能瓶颈的不合理的设计或者是编码或者是配置，最后分享了

项目上有 Full GC 告警，每个节点平均每天有一到两次Full GC 告警。出现Full GC时，应用是处于 Stop The World 状态，对于高可用要求的应用来说，这是一个很大的稳定

如何打印生产的堆栈信息，如何将系统线程在映射到java的线程，如何快速定位死锁，快速定位CPU飙高的原因，今天这篇文章带你搞定。

如果我们现在在搭建新的业务架构，如果说你们未来的业务数据量会达到千万 或者上亿的级别 还在一股脑的使用分库分表的架构，那么你们的技术负责人真的就应该提前退休了

昨天在技术群聊中，发现两个震惊的观点今天就分享出来吧 最开始一个兄弟说 “逻辑删除标识的条件不能放在第一个” 后面又一个兄弟说 “条件的顺序会影响索引的使用，会按照条件的顺序查询”

前言 今天的主题就是聊一聊，spring task 和 Quartz 如何实现任务的定时执行的。 关于spring task 和 Quartz 两个任务中间件，之前写过一篇原理分析的，有兴趣的可以看看

程序抛出Read timed out 这个问题已经出现过一年多了，之前因为这个问题导致定时任务运行一段时间就停止、报名重复等一系列问题，这个问题的本质就是：程序向数据库发送了commit指令之后