InvocationHandlerInvocationHandler 接口是 Java 动态代理的核心部分，它里面有一个方法 invoke 当使用动态代理创建一个代理对象时，所有对代理对象的方法调用都会被路由到实现了 InvocationHandler 接口的 invoke 方法 1234567891011121314public class MapperProxy<T> imple

安全点HotSpot 虚拟机并非在代码指令流的任意位置都能停下来开始垃圾回收的，而是强制要求必须执行到安全点后才能够暂停 安全点的选定基本上是以“是否具有让程序长时间执行的特征” 为标准进行选定的，最明显的特征是指令系列的复用，所以只有具有这些功能的指令才会产生安全点 方法调用 循环跳转 异常跳转 循环HotSpot 虚拟机为了避免安全点过多带来过重的负担，对循环有一项优化措施，认为循环次数较

Redis 做延迟队列有两种方案： Redis 过期时间监听 Redisson 内置的延迟队列 Redis 过期事件监听实现延迟队列Redis 有发布订阅（pub/sub）功能，在 pub/sub，引入了 channel（频道），类似于消息队列的 topic （主题） pub/sub 涉及发布者publisher 和 订阅者 subscriber 两个角色 发布

Timeline本文介绍基于关注关系并按时间排列的 Feed 流 Feed 流有两种工作模式，推模式和拉模式 拉模式在用户查询时应该首先查询用户关注的所有博主的 uid 查询他们发布的作品，最后按照发布时间降序排列 拉模式用户每打开一次 “关注页” 系统就需要读取 N 个人的文章（N 为用户关注的博主数）所以拉模式又被称为读扩散 拉模式不需要额外存储数据 发布文章在 articles 表增加一条

点赞内容点赞是一个非常高频的业务场景，功能本身复杂度不高，但是业务场景多，QPS 高，而且由于社区的用户体量，整体点赞的数据量非常大 点赞服务需要提供的接口有 对某个内容点赞（取消点赞）、点踩（取消点踩） 查询是否对 单个 或者 一批内容 点过赞（踩） - 即点赞状态查询 查询某个内容的点赞数 查询某个用户的点赞列表 查询某个内容的点赞人列表 查询用户收到的总点赞数 其中最核心的主要是 用户

观察者模式是一种一对多的关系，当一个对象状态发生改变时，所有依赖于它的对象都得到通知并完成更新 被观察者（Observerable）：目标对象，状态发生变化时，通知所有的观察者 观察者（Observer）：接收被观察者状态变化通知 例如异步通知场景 定义被观察者 12345678910111213141516171819202122232425262728293031public clas

责任链允许请求沿着处理者链进行处理，类似于拦截器 责任链由三部分组成 抽象处理者（Handler）：定义一个处理请求的抽象类，包含处理方法和一个 next 指针 具体处理者：实现抽象处理者方法 客户端 抽象处理者 123456789public abstract class GatewayHandler { protected GatewayHandler next; p

定义操作中的骨架流程，将一些步骤延迟加载到子类中，使子类可以不改变结构即可重新定义该流程的特定步骤 一个抽象类，定义骨架流程 例如一个请求经过流程分为如下步骤 解析请求头 封装数据 返回请求体 1234567891011121314public abstract class AbstractRequestService { abstract void resolveHead

有多个 if...else 等条件分支，并且每个条件分支，可以封装起来替换的，可以使用策略模式来优化 一个接口 12345678910111213public interface IFileStrategy { /** * 输入哪种文件类型 * @return */ FileTypeEnum getFileType(); /** *

如果一个消息队列对某个消息发送了两次，导致入库两条相同的数据，如何避免 也即如何保证幂等性，接下来讨论的前提是全局唯一 ID 唯一索引最简单的方案，先查 ID 在数据库里有没有，如果没有则入库 1234vo = select(id);if (vo == null){ save(信息)} 先查询，再判断，再保存，在多线程的情况下，还是拦不住 可以在数据表中加唯一索引方案解