roykingw的专栏

现在IT大环境下滑，开始催生出了一个程序员极地求生新技能：防御性编程。​ 原本防御性编程的意思是在写业务代码时应该要更多的考过各种可能出现的边界情况，做更多防御性的考量。但是，防御性编程有了新的含义。那就是让我的代码只有我能看懂，别人都看不懂。这样，别人就无法抢我的饭碗了。老板裁员时自然也要掂量掂量了。

文章摘要： Redis之所以快，关键在于其精细化的内存管理和数据结构设计。源码分析揭示，Redis根据value类型采用不同存储策略：1) 数字类型使用int直接存储，并复用缓存对象；2) 短字符串(≤44字节)采用embstr紧凑存储，将字符串与redisObject连续存放；3) 大字符串使用raw类型分散存储。此外，Redis通过预定义SDS(Simple Dynamic String)结构，采用固定长度的内存分配策略，避免了C语言字符串的缺陷，提升了内存访问效率。这种底层优化使Redis在内存操作上

面试题就是一没有体系化的基础知识作为支撑，二没有明确的项目环境作为背景，零零散散的到处聊聊天而已，却偏偏要为了一点流量装个逼。一整个机构的人，天天专业的忙乎着这点事情，赚点生活费，到头来还不如你这时不时的出来蹦跶两下？一帮帮人，从小白学java，最少也要学个年把，好不容易到了要出山的时候了，你们一个劲的鼓吹他们白学了，趁早转行。在这个连公务员，老师的饭碗都端不稳的时代，各行各业都应该要抱团取暖的时候，你们一个个来拆柱子，属实可恶。最后，java的行情确实不好，但是，这是个大环境，不是java的祸。

​ 关于DDD，大部分朋友应该都听说过。 全称是Dmoain Driven Design，翻译过来就是领域驱动设计。这个神秘的架构思想，虽然远没有SpringBoot这类框架这么名声在外，但是却经常时不时冒出来，牵动一下大家的神经。美团、阿里每年的技术年会都会有关于DDD的经验分享，而另一方面，又有移动、电信等公司爆出DDD从入门到放弃的失败案例。​ 那么到底什么是领域驱动设计呢？是不是用上了DDD的所谓四层架构，就是在用DDD了？其实DDD这东西看起来挺抽象，但是核心就是需要搞明白三个问题。

如果面试问你，你会做一个权限系统吗？那你肯定会说做过。不就是各种登录、验证吗。我做的第一个CRUD应用就是注册、登录。简单！但是，如果问你在工作中真的做过权限系统吗？其实很多人都只能默默摇摇头。因为在很多真实项目中，权限系统可能不是最复杂的，但一定是牵连最广的。因此往往大型项目中真正去做权限系统的，都只是非常核心的一小部分人。而如果你的应用越来越复杂，作为安全门户的权限系统也会随着变得更加复杂。各种方案层出不穷。

​ 我们写的Java应用，都是以Jar包的形式发布的，所以对于Jar包，你一定习以为常。但是，如果你有一天打开一下JDK9以后的版本在你本地的安装目录，你会发现，JDK中那些熟悉的jar包，完全不见了。取而代之的是一些jmod文件。​ 甚至在熟悉的IDEA里，JDK的包下也不再是一个个Jar包，而变成了一个个与这些jmod文件对应的模块。​ 这些jmod文件是什么呢？​ 其实这些jmod文件可以认为是一种特殊的jar包。JMOD设计为在编译时间和链接时间使用，但不在运行时使用。

人生三大境界，见山是山，见山不是山，见山还是山！​ 学了好多年Java，你知道你写的java代码到底是什么样子的吗？k=k++，这样一个简单的代码，就足够考验考验Java程序员的斤两。​ 类似这样的非人类代码的面试题，其实不在少数。这一类面试题，想要考验的，从来不仅仅是程序员的代码理解能力，而是对语言底层逻辑的熟悉程度。​ 如果你是一个刚入门的Java新手，那么，对于这一类问题，只要能够推断出执行的结果就行了。

MySQL，是现在业界最受欢迎的关系型数据库之一，他的好处毋庸置疑。但是这也让MySQL成了面试中的重灾区。到底要怎么理解MySQL那些复杂又神秘的底层架构呢？这次楼兰就带你从日志系统出发，快速解析MySQL的整体架构设计。​ MySQL的日志文件分为redolog，undolog和binlog三种。这些复杂的日志文件分别是干什么的？有什么关系？接下来我们就一层层的来拆解MySQL。

各位伟大的Java程序员，现在有一条财富自由的路摆在你的面前，你有没有信心为此去挑战一下自己？​ 这次我们来聊一个比较有意思的话题，如何防止Class文件被反编译。

现在面试动不动就是问三高架构。应用大了，数据量多了，查询性能自然就下降了。怎么办呢？很多人自然就想到分库分表。但是一旦把底层数据库给拆分开了，在业务层面就会暴露出很多问题。那么在一个具体的业务场景下，要如何设计分库分表方案，并对方案进行优化呢？这次就以用户信息这个具体的场景来分享下如何设计分库分表方案。

@Autowired和@Resource这两个注解的功能都差不多，都是在Spring框架中做自动注入的。但是他们有什么区别呢？楼兰带你来分析分析

同步刷盘，异步刷盘？同步同步，异步同步？零拷贝，顺序写？你是不是曾经在各种各样的流量短视频和博客中听说过跟RocketMQ相关的这些亮瞎眼的高大上的技术名词？你有没有想过自己去RocketMQ中看看这些概念背后的Java代码是什么样的？如果你有过这样的想法，那么，楼兰到你到RocketMQ的源码当中逛逛，看看RocketMQ的大神们，是如何用简单常见的MVC思想开发出RocketMQ这样的神作的。

比如在分布式场景下做用户登录功能，我们就可以将用户信息以JSON字符串的形式保存到Redis中，来代替单体应用中的Session，从而实现统一的登录状态管理。哈希函数的选择对过滤器的性能有很大影响，理想的哈希函数应该具有良好的散列性，使得不同的输入尽可能均匀地映射到位数组的不同位置。通常使用的 keys * 这样的指令，在生产环境一般都是直接禁用的，因为这样会产生严重的线程阻塞，影响其他的读写操作。所以，在布隆过滤器的初始化过程中，通常只需要指定过滤器的容量和误判率，就足够了。相对的，算法实现也就更复杂。

​ 使用CompletableFuture，程序员可以很方便的控制线程的执行顺序。包括串行、并行或者多个线程的组合与转化功能。​ CompletableFuture主要实现了两个关键接口：Future：Future是一个代表异步计算结果的对象。它允许你从一个异步操作中获取结果（一旦结果可用），取消正在执行的计算，或者检查计算是否已经完成。Future 通常与 ExecutorService 结合使用来提交任务，并且是 java.util.concurrent 包的一部分.

程序员短视频上瘾综合症

JVM 调优快速上手指南。最快速度带你上手虚无神秘的 JVM 调优。

​ 关于中年危机，网上已经有了各种各样的解读。但是，这两天一个学员跟我简单几句聊天，却触发了对于中年危机的另一种思考。如果你曾经也有点迷茫，或许你可以稍微花几分钟看下这个故事。

RocketMQ 5.x版本快速上手

所有Follower Partition上报后，Leader Partition才能更新HW的值，然后Follower Partition在下次拉取消息时，才能更新HW值。当Leader Partition出现切换，所有的Follower Partition都按照自己的HW进行数据恢复，就会出现数据不一致的情况。所以在很多对性能要求比较高的线上环境，会选择关闭Kafka的这个Leader Partiton自平衡操作，而用其他运维的方式手动进行Leader Partiton自平衡，尽量减少自平衡过程。

而在一个Partition的众多备份中，需要选举出一个Leader Partition，负责对接所有的客户端请求，并将消息优先保存，然后再通知其他Follower Partition来同步消息。​ 当一个集群内的Kafka服务启动时，就会尝试往Zookeeper上创建一个/controller临时节点，并将自己的brokerid写入这个节点。​ 选举产生的Controller节点，就会负责监听Zookeeper中的其他一些关键节点，触发集群的相关管理工作。

​ 这一部分主要是理解Kafka的服务端重要原理。但是Kafak为了保证高吞吐，高性能，很多具体实现都是相当复杂的。如果直接跳进去学习研究，很快就会晕头转向。所以，找一个简单清晰的主线就显得尤为重要。这一部分主要是从存储的角度来理解Kafka的Broker运行机制。这对于上一章节建立的简单模型，是一个很好的细节补充。​ Kafka依赖很多的存储数据，但是，总体上是有划分的。Kafka会将每个服务的不同之处，也就是状态信息，保存到Zookeeper中。

快速、系统掌握Kafka生产者消息事务

Kafka消息发送幂等性

快速理解Kafka的发送应答机制

快速理解Kafka的消息路由机制

快速理解Kafka的消息序列化机制

​ 关于Kafka保证消息不丢失的问题，就简单总结到这里，但这其实并不是结束。相反，随着你对Kafka理解得越深，你会发现这个问题会有更多的发散空间。像MQ如何保证消息不丢失？如何不重复消费？如何处理消息积压？等等，这都是一系列非常开放的面试题。对于你是否真正理解了每个MQ产品，是非常好的检验标准。所以，这么好的题目，如果只是简简单单背个八股文，那太可惜了。...

Kafka的HighLevel API的重要目的就是想要简化客户端的使用方式，所以对于API的使用，尽量熟练就可以了。对于其他重要的属性，都可以通过源码中的描述去学习，并且可以设计一些场景去进行验证。其重点，是要逐步在脑海之中建立一个Message在Kafka集群中进行流转的基础模型。​ 其实Kafka的设计精髓，是在网络不稳定，服务也随时会崩溃的这些作死的复杂场景下，如何保证消息的高并发、高吞吐，那才是Kafka最为精妙的地方。但是要理解那些复杂的问题，都是需要建立在这个基础模型基础上的。...

​ 这一部分主要是从客户端使用的角度来理解Kakfa的重要机制。重点依然是要建立自己脑海中的Kafka消费模型。Kafka的HighLevel API使用是非常简单的，所以梳理模型时也要尽量简单化，主线清晰，细节慢慢扩展。...

言简意赅，快速从零开始构建Kafka整体知识体系，有问题回头再来查。

消费者端存储广播消费的本地offsets文件的默认缓存目录是 System.getProperty(“user.home”) + File.separator + “.rocketmq_offsets” ，可以通过定制 rocketmq.client.localOffsetStoreDir 系统属性进行修改。本地offsets文件在缓存目录中的具体位置与消费者的clientIp 和 instanceName有关。...

​ 关于MyCat，不用做过多介绍，曾经大名鼎鼎的分库分表中间件。诞生于2013年，从MyCat1.6版本之后，陷入了一段时间的沉寂。从2021年11月低开始，重新推出新版本的MyCat2，官网地址：http://www.mycat.org.cn/ 。​ 重要特性一目了然，独立，是他最大的标签。然后在他的Git仓库中，对产品有一个简单的介绍：​ 立足于Sharding分库分表。简单、快速是MyCat2对自己最直白的声明。他的定位其实是代表了一整套基于MySQL的分布式数据处理系统，可以让MySQL拥有堪比

一套框架，带你对接所有的MQ产品。

文章目录一、整体理解新版本二、5.X部分新特性1、DistSQL2、可插拔内核3、数据迁移三、全部内容总结一、整体理解新版本​ ShardingSphere在2021年十月份推出了5.0的第一个发布版本，并在2022年一月份推出了5.1版本。从整体来看，ShardingSphere5.x将自己的功能定位从数据库中间件升级到了DataBase Plus，数据库功能增强。核心产品定位的变化，必然会带来非常多的改变。不过从功能方面来看，目前5.X版本还只是做了一些功能增强，但是核心功能并没有太大的变动。很多规

DDD真的来了。后微服务时代，软件系统越来越庞大，也越来越老化。需求越来越模糊，代码越来越混乱，测试越来越困难，技术演进也基本不可能。大型软件项目很快从充满朝气的，充满竞争力的青年，变成了不求变，不敢变的老年。如何解决系统老化的问题？DDD领域驱动设计成了业界最大的希望。各大厂都在落地DDD，还不知道DDD？那就真的OUT了。大龄程序员如何提高竞争力？靠你的技术实力吗？信息爆炸的时代，你会的技术别人分分钟就能学会，凭什么来拉开你与别人的差距？其实方法都知道，提升架构思维，设计高质量的架构，写高质量的代码

文章目录一、堆内内存与堆外内存二、内存对象初始化三、内存数据读写四、内存释放五、Cleaner机制和Finalizer机制六、JAVA四种引用类型七、章节总结 === 楼兰 ===​ 这一节，将重点来讨论NIO中的Buffer。彻底理解清楚Buffer是个什么样的东西。 一、堆内内存与堆外内存​ 关于Buffer，在基础篇中已经做过简单介绍。他是网络IO数据与本地数据的缓冲。Nio中相关数据都是通过Buffer来携带。在这一部分，就来深入看看这个Buffer到底是什么。​ 实际上Buff

文章目录一、Channel与流的区别二、从文件读写看IO到底会不会丢数据1、神奇的文件丢失现象。2、使用Channel保证数据不丢失。三、Page Cache机制解读四、进阶篇总结​ 这一节将来讨论NIO中最后一个组件，Channel。并讨论一个重要的问题， IO到底会不会丢数据。一、Channel与流的区别​ 在传统的标准IO下，java程序需要进行一些IO操作，例如读写文件，都只能通过流来进行。而在JDK1.4版本以后，java的NIO包中提供了另外一种增强版的IO操作方式， Channel。首先

文章目录一、进阶篇：Netty封装了什么？二、刨根问底：到底什么是阻塞？什么是多路复用器？1、操作系统基础1-1 用户态与内核态1-2 系统调用1-3 File Descriptor 文件描述符1-4 简单跟踪程序的系统调用过程2、多路复用的流程3、调试NIO的系统调用三、章节总结一、进阶篇：Netty封装了什么？​ 之前整理的整个Netty篇，快速的完成了从BIO到Netty的进化，但是始终会有一个感觉，就是这些网络IO的代码有点别扭，有很多代码之间的逻辑需要强行去记忆。这个番外篇我们就会深入底层去探

一、内容与特点​ JUC主要是指JDK8中java.util.concurrent里提供的一系列线程并发工具，但是线程并发的问题远不止几个工具这么简单。要学习工具使用，更要能深入理解工具的原理以及处理线程并发问题的思路。​ 新手学技术、老手学体系，高手学格局。二、理解线程1、线程与进程​ 进程是操作系统中分配资源的最小单位，线程是CPU调度运行的最小单位。同一个进程下分配多个线程，这些线程可以共享进程内的资源。​ 现在的CPU都是有多个核心独立运行的，所以使用多线程能够更多的使用CPU的性能。并

文章目录一、传递POJO二、Google Protobuf三、TCP粘包与拆包四、心跳检测五、Netty整合Log4j六、WebSocket七、Netty群聊八、Netty实现RPC服务调用九、短连接与长连接配合示例代码​ 这一篇我们就玩起来，通过一些常用的实战问题，来理解如何使用Netty进行网络编程。一、传递POJO​ 第一个示例参见示例代码中的com.roy.netty.pojoTransfer。​ 这个示例实现的功能是这样的：1、客户端建立连接后，就会往服务端发送一个User对象。