在新版本应用发布时，为了服务器不停机升级，使用灰度发布策略，在灰度发布开始时，使用 HTTP Header 匹配指定测试人员的流量到新版本上，然后当新版本内部测试通过后，可以再按百分比，将用户流量一点一点导入到新版本中，比如先导入 10% 观察一下运行情况，然后再导入 20%，如此累加，直到将流量全部导入到新版本上，最后完成升级，如果期间发现问题，就立即取消升级，将流量切回到老版本。运用灰度发布，

泛型概述：泛型表现为一种类型，但泛型的本质是参数化类型，也就是说所操作的数据类型被指定为一个参数泛型是在编译时被确定常见通配符：？：表示不确定的 java 类型，即可以存N种类型；即使初始化的时候指定了类型也可以存任意类型T (type)： 表示具体的一个java类型E (element) ：代表Element，与 T 意义基本无差K V (key value)： 分别代表java键值中的Key

1.消息过期时间（TTL）有两种设置方式：1.1 Queue TTL所有队列中的消息超过时间未被消费时都会过期，通过队列属性设置消息过期时间// 使用SpringAMQP声明队列@Bean("ttlQueue")public Queue queue(){Map<String,Object> map = new HashMap<String,Object>();map.put

首先思考一个问题，整个Tomcat容器是一个Java进程，假若Tomcat中同时部署了两个应用，应用A依赖Spring3.0，应用B依赖Spring5.0，那么Tomcat如何决定使用哪个版本的依赖呢。所以，按照JDK自带的双亲委派模型是无法解决的，因为ClassLoader#loaderClass默认会检查这个类有没有加载过，保证了类在进程中是唯一的。如果我们想加载两个版本的类，需要打破原有的模

哈希算法将任意长度的二进制值串映 射为固定长度的二进制值串，这个映射的规则就是哈希算法，通过原始数据映射之后得到的二进制值串就是哈希值需要满足的几点要求从哈希值不能反向推导出原始数据（所以哈希算法也叫单向哈希算法）；对输入数据非常敏感，哪怕原始数据只修改了一个 Bit，最后得到的哈希值也大不相同；散列冲突的概率要很小，对于不同的原始数据，哈希值相同的概率非常小；哈希算法的执行效率要尽量高效，针对较

1.keys：全量遍历键keys & scan 这两个方法都用于key的模糊查询用来列出所有满足特定正则字符串规则的 key，当redis数据量比较大时，性能比较差，要避免使用keys *xxx // abcxxxkeys xxx* // xxxabckeys xx*xx //xxabcxx2.scan：渐进式遍历键scan (cursor) match (xxx *) count (li

随着 JVM 虚拟机和 JIT即时编译技术的发展，对象的分配和回收是个非常轻量级的工作。但是对于缓冲区 Buffer，情况却稍有不同，特别是对于堆外直接内存的分配和回收，是一件耗时的操作。为了尽量重用缓冲区，Netty 提供了基于内存池的缓冲区重用机制。 Netty ByteBuf 继承关系如下1.性能对比测试Netty 提供了多种内存管理策略，通过在启动辅助类中配置相关参数，可以实现差异化的定制

1.synchronized优化方案1.1 锁消除锁消除即删除不必要的加锁操作。虚拟机即时编辑器在运行时，对一些“代码上要求同步，但是被检测到不可能存在共享数据竞争”的锁进行消除。根据代码逃逸技术，如果判断到一段代码中，堆上的数据不会逃逸出当前线程，那么可以认为这段代码是线程安全的，不必要加锁。看下面这段程序：public class SynchronizedTest {public static

1.对象存储布局一个Java对象在内存中包括3个部分：对象头、实例数据和对齐填充1.1 对象头Mark Word状态标识。与虚拟机位数一样，一般64bit，32bit很少。下图是一个32位虚拟机的Mark Word示例：从对象头中可以获取到两点信息：Minor GC年龄默认15，是因为分代年龄只有4bit，最大就是15有锁状态无HashCode是因为没空间存了Klass Pointer指针，指向相

1 Java线程模型Java语言的线程，从规范的角度来说是不强制要求任何具体的实现方式的。采用1:1、N:1、M:N模型都可以。先放个传送门：RednaxelaFX：JVM中的线程模型是用户级的么？N : 1（JDK2前）Java线程在JDK1.2之前，是基于称为“绿色线程”（Green Threads）的用户线程实现的，而在JDK1.2中，线程模型替换为基于操作系统原生线程模型来实现。因此，在目