简介

在我潮汕地区，茶是必不可少的，人们品尝就跟喝水一样平常，但茶却包含了很多学问和人生道理。茶之道，在于心境的平和，人生如茶，沉时坦然，浮时淡然，沉浮之间，淡然处之，可谓茶壶虽小，内涵乾坤。自古以来，以茶会友，以茶道来醒悟人生之道。可以说茶就好像国外的咖啡一样，而咖啡正是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应用

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

学习笔记
Recycler对象池

linux

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

mybatis

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

设计模式

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

场景设计

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

算法

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

问题排查

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

工具

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.避免过度设计绝对不是“不设计”，需要把握好度，不要走两个极端。
  这里有一些过度设计的案例，其中有一些我们也会犯错的场景，如只有一种类型，就搞个泛型，动不动就定义一个接口。

概念

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

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

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

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

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

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

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

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

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

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

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

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

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

经验总结

• 阿里java开发规范
  阿里团队多年编程总结，最佳实践，可以用来作为团队开发规范。

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

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

• 接口设计
  为上层提供接口(方法)应该从领域出发，保持一定的通用性，避免接口(方法)膨胀。

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

• 生产上执行语句要非常小心
  生产上的操作都需要仔细，确保不会出错，最好有回滚措施。举例：在使用跳板机查看redis集合内容时，不小心遍历一个大的集合，导致业务操作都阻塞。

• 日志很重要
  有效的日志有时候是排查问题唯一的方式，例如要追溯一个较久前的数据。反之，无效无用的日志不要打。

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

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