简介

在我潮汕地区，茶是必不可少的，人们品尝就跟喝水一样平常，但茶却包含了很多学问和人生道理。茶之道，在于心境的平和，人生如茶，沉时坦然，浮时淡然，沉浮之间，淡然处之，可谓茶壶虽小，内涵乾坤。自古以来，以茶会友，以茶道来醒悟人生之道。可以说茶就好像国外的咖啡一样，而咖啡正是java的原意，这也是本仓库命名的由来。在技术的道路上，需要不断的醒悟和感悟，技术的远方是无止境的，但只要以平和的心态持之以恒，终能有所收获。

目录

spring/spring boot/cloud

spring bean生命周期
spring session统计登录人数
spring容器初始化完成事件
spring循环依赖
@Async循环依赖分析
spring cloud gateway + nacos
spring cloud gateway filter
eureka 原理/集群
feign
服务优雅下线
动态创建bean托管到spring
除了java-jar,还能这样运行你的springboot应用
网关限流实战
feign监控

webflux

错误处理
日志追踪
全局异常处理
expand递归
swagger
debug
map&flatMap
源码分析

java基础

@Transactional不生效?
java开发规范
什么？@Transactional又不生效了？
cas
java集合类型-Queue继承体系
happend before
java内省机制
并发工具类Phaser
cglib FastClass机制
异常处理机制
使用线程池你应该知道的知识点
泛型

jvm

jvm常用参数
jdk常用命令
TLAB堆内存中的线程私有区域
三色标记法

mysql

锁简介
数据库开发规范
mysql三种log
一条危险的update语句
使用p6spy监控应用sql
这么分页查数据居然重复了
MVCC原理
深入理解索引
sql到底慢在哪里
order by居然有bug?
mysql到底有没有解决幻读问题
[buffer pool]
我又遇到order by的坑了
这样delete居然不走索引

redis

详解redis网络IO模型
redis常用配置参数
resp协议
redis单机和集群搭建
缓存和数据库一致性问题
分布式锁
string类型底层SDS
redis geo地理空间
zset
zset实践
hash
持久化机制
使用Pipeline提升性能

中间件

nacos集群
canal简介
canal quick start
canal server ha
apache common pool2
熔断-hystrix
熔断-resilience4j
熔断-sentinel
使用MapStruct替换BeanUtils
加强版ThreadPoolExecutor
加强版ThreadPoolExecutor升级
给xxl新增tranceId&spanId

kafka

kafka消费者重启消息重复消费
kafka错误日志问题
kafka分区分配策略
patition扩容后如何保证消息顺序性
spring kafka重试机制

elasticsearch

核心概念
倒排索引
es/kibana/集群/cerebro搭建
分词
常用api
es写入原理
使用java访问es
es中的分页

netty

netty学习笔记
Recycler对象池

linux

基础命令
实操
系统
五种IO模型
零复制
顺序IO

mybatis

核心组件
springboot是如何集成mybatis的

设计模式

在同事的代码中学习-责任链模式

场景设计

分层设计
mq多环境topic设计
解决多环境下微服务实例乱窜

算法

使用TreeSet优化任务分配.md
限流算法
[时间轮算法]
[缓存淘汰算法]
一致性hash算法
比例分配算法
手写lru

问题排查

java cpu占用高问题排查
java 内存占用高问题排查
HttpClient线程池设置问题
rm命令删除文件了,但磁盘空间没有释放
一次内存泄漏排查
一次redis带宽占用高分析
线程池shutdown引发TimeoutException
一次服务启动慢问题排查
redisson内存泄漏问题排查
线程安全问题

工具

arthas实践
arthas tunnel,集中管理所有agent
git
git hook解决多仓库代码合规问题
ssh多个远端仓库
jmeter
curl
idea插件汇总
写一个idea插件通知你gitlab远端分支变更了

面试

双亲委派机制
jdk动态代理与cglib
tcp三次握手四次挥手
CountDownLatch和CyclicBarrier
并发编程wait和notify
面试再也不怕问ThreadLocal了

其它

druid加密
jasypt加密配置文件
ThreadLocal扩展
单元测试启动加速
如何优雅的统计方法执行时间
如何做好code reivew
为了简写这行代码，我竟使用静态和动态编译技术
这下对阿里java这几条规范有更深理解了

编程原则

• kiss原则
  keep it simple and stupid，保持简单，意思不要把东西搞得复杂。

• 单一职责原则
  说明：单一职责原则包括方法职责单一，类职责单一，模块职责单一等，一个方法只做一件事情有很多好处，例如代码阅读起来更舒服，后期维护更方便。
  经常看到我们的代码方法参数非常长，有的甚至达到10个左右，很明显就违反了单一职责，这个方法做了太多事情。

• 开闭原则
  说明：对扩展开放，对修改封闭。这意味着我们的方法，类，模块，在新增功能时，是可以通过扩展实现的，而不需要去修改原来的代码。
  这样做的好处是可以动态增删功能，且因为没有修改原来的代码，不需要对原来的代码进行审查，单元测试，出错的可能性大大降低。
  维基百科

• 高内聚原则
  说明：高内聚可以理解为相同的业务、逻辑都应该由一个对象处理，这个对象可以是类，方法，接口等，而不应该把这些逻辑分散到各个地方。
  比如后期逻辑需要调整，高内聚的设计优势就非常明显，只需要修改很小的地方，而如果代码分散在各个地方，改起来就非常麻烦，而且容易出错。

• Rule Of Three，三次原则
  含义：当你第一次用到某个功能时，编写一个特定的方法完成它。当你第二次又用到它时，拷贝上一次的代码。当你第三次再遇到，才考虑着手优化，通过设计写出通用的方法。
  说明：原则的主要思想是避免过度设计，过度设计除了会浪费我们的时间，还会让本来简单的代码复杂化，增加维护成本。
  原则具有指导性，但有两点需要提醒下：
  1.我们需要根据实际情况来判断，例如我比较推荐“二次原则“，当一个功能出现第二次的时候，建议就着手优化。
  2.避免过度设计绝对不是“不设计”，需要把握好度，不要走两个极端。
  这里有一些过度设计的案例，其中有一些我们也会犯错的场景，如只有一种类型，就搞个泛型，动不动就定义一个接口。

• 弱依赖原则
  说明：强依赖，没有A，B就做不下去；弱依赖，没有A，B依然可以做下去，只不过少了一些功能。弱依赖的思想随处可见，如降级，兜底策略，包括我们代码设计也是一样。
  举例：使用springcloud gateway RedisRateLimiter基于redis限流时，作者就使用了弱依赖原则，当redis出现故障时，限流功能会暂时失效，请求放行。

概念

• 蝴蝶效应
  亚马逊河一只蝴蝶煽动翅膀，可能引起周边环境的变化，进而引起更多的天气反应，造成龙卷风。一个很小的问题，可能引起一系列反应，变成一个很大的问题。

• 墨菲定律
  如果事情有可能变坏，无论这种可能性有多小，它总会发生。

• 破窗效应
  如果一扇窗破了，其它的窗在不久内也会一起破掉。有个地方代码写得烂，那么不久，就会有越来越多的烂代码，导致项目的可维护性越来越低。

• 鲁棒性
  指在系统某些参数的抖动下，仍然维持它的某些特性（性能、稳定）。

• 背压
  当消费者消费数据的顺序小于生产者的顺序，通知生产者较低生产速度。

• 康威定律
  一口气吃不了一个胖子，能搞定的先搞定。大而复杂的系统更倾向于分解，合久必分，分而治之，独立子系统可减少沟通成本。

• 让营地比来时更干净
  美国童子军谚语，美国童子军相当于半军事化管理的夏令营，每次孩子们离开时都需要打扫干净，让营地比来时更干净。反应到软件开发中，就是不要破坏规则，不要引入混乱，每次提交代码都要比上次更优。

• 好莱坞法则
  演员只需要把简历交给好莱坞演艺公司就可以了，后面的流程由好莱坞全面控制。“不要给我们打电话，我们会给你打电话”，表明了绝对控制权。

• 大拇指法则
  又叫经验法则，是一种简单的，经验性的，探索性的，但不是很准确的原则。

• 悲观思维
  开发过程中要保持一种悲观思维，类似于悲观锁一样，想法悲观，认为各种情况都可能出现问题，这样就能做好防范，保证程序的健壮性。

• 奥卡姆剃刀原理
  如何必要，勿增实体。化繁为简，抓住重点。关注核心和关键点，不做一些没有必要的事情。

• 读扩散，写扩散
  读扩散：发布者写数据时只写自己一份，读数据时订阅者都要去发布者那里拉取。特点：写时简单，读时复杂。
  写扩散：发布者写数据时除了写自己一份，还要写到各个订阅者那里去，读数据时订阅者不需要去发布者那里读取，只需要读自己的数据。特点：写时复杂，读时简单。

• 马太效应
  马太效应（Matthew Effect）是一个由社会学家罗伯特·K·默顿（Robert K. Merton）于20世纪中期提出的概念，其名称来源于《圣经》中的《马太福音》。它描述了一种常见的社会心理现象，即优势往往会产生更多的优势。 老子的《道德经》第七十七章也有类似的表述，“天之道，损有余而补不足。人之道，则不然，损不足以奉有余”。
  形容好的更好，坏的更坏，多的更多，少的更少。在程序应用中，当kafka consumer消费落后，lag变大，会出现索引项也不在page cache，进而要从磁盘读取的更糟糕现象。

• 惊群效应
  当所有线程（进程）在阻塞等待资源的时候，当资源释放，所有线程都会唤醒去获取资源，但最终只有一个能获取到，其它线程又重新进入阻塞等待，白白经历唤醒-等待这个过程。
  往一群鸽子投喂一个实物，所有的鸽子都会过来抢，但只有一只能抢到。惊群现象对系统性能有较大的影响，需要尽量避免。

经验总结

• 时刻考虑性能问题
  包括调用对方接口性能，sql查询，算法复杂度，使用正确的数据结构等。
  在高并发场景下，性能问题会加倍放大，稍不注意，很容易导致整个服务挂掉。

• 不信任任何外部
  不要信任前端，不要信任第三方服务，对所有可能的情况都应该进行校验。

• 抽象设计
  抽象设计可以保证更好的通用性和扩展性。例如代码抽象接口，以后可以扩展更多具体行为。例如接口设计，从领域出发，保持一定的通用性，避免接口膨胀。
  举例：笔者在2018年接触k8s，近期(2024)又在看，这么多年过去了，它里面的核心概念几乎没变过。

• 敬畏生产环境
  涉及到生产上的操作都需要仔细，确保不会出错，最好有回滚措施，最好不要自己操作，走审批流程由负责人操作。

• 日志很重要
  日志很重要，日志很重要，日志很重要，重要的事情说三遍。
  有效的日志可能是排查问题唯一的方式，观察程序的运行情况，追溯历史数据。反之，无效无用的日志不要打。

• 监控很重要
  监控可以辅助提醒，发现问题。在需求或技术方案设计阶段就要考虑如何做监控，核心接口一定要做监控。
  举例：接口响应状态码，接口调用失败次数，接口多久没调用量，异常日志次数。

• 兜底方案
  说明：不只代码，凡事都要考虑兜底方案，包括为人处事，这条主路走不通了，如何兜底不至于完全走不了。
  在需求或技术方案设计阶段较要考虑兜底方案，主线先确立，然后每一步都要考虑如何兜底。

• 多看官方文档
  官方文档才是权威，标准的解决方案。
  举例：笔者曾经遇到一个坑，阿里云redis集群对lua脚本做了特殊限制，导致程序报错，网上的解决方案都很复杂，实现成本高。实际在阿里云官方文档做了说明，针对这种情况关闭一个参数即可，你看，非常简单就解决问题。

• 不要忽略细节
  在一次接口对接中，我发现对方有一个单词拼写错误写少一个l字母，我觉得不需要告诉对方，并且对接不报错即可。过了许久，我在另一个项目也需要对接这个接口，我已经忘记这个单词错误问题，并且直接写对的单词，造成了一个bug。

• 不只代码
  工作中不只程序，人事关系，职场规则，如何与不同性格的人相处，控制情绪，提高说话的艺术，这很重要。

• 做好准备
  汇报工作，安排工作，讨论方案，技术分享...什么事情要提前做好准备，才能有底气，不会被别人带节奏，打有准备的战。
  举例：讨论方案，对方给了一个方案，开始你没准备好，对方解释得头头是道，大家都觉得可以，后来你发现你有更好方案，但已经和别人定好，没用了，如果能提前准备好，价值就能体现。

• 成本问题
  新手上来通常都是代码一把梭，各种api调用看起来很6，实际却很少考虑周全，经不起推敲。
  这里所说的成本包括开发成本和价格成本。
  开发成本很好理解，我们希望选择一个开发、维护成本最小的可达成目标的实现方式，很多时候都是没有“最好”只有最“合适”，所以做方案选择的时候开发成本也是一个重要考虑因素。
  价格成本就是实际的钱了，例如部署服务，各种中间件最小需要什么配置，而不是随意申请一个配置高的，配置高意味着价格贵，这种情况在笔者工作生涯也是屡见不鲜。再比如调用某些第三方服务需要收费，那就要考虑调用结果缓存，减少调用次数，限流等。
  虽然省下来的钱老板也不会给你加工资(扎心~)，不过作为一个有理想的程序员，还是要严格要求自己。

面试/招聘

涵盖：java基础，jvm，spring/boot/cloud，数据库，redis，mq，netty，分布式相关技术，容器等等...
持续完善中，欢迎关注：https://www.processon.com/embed/6720bd5c6b5a4a4adda5eac9?cid=6720bd5c6b5a4a4adda5eacc