JVM内存模型 Java虚拟机（JVM）内存模型是Java运行时数据区的一种规范，它定义了Java虚拟机在执行Java程序时如何使用内存。了解JVM内存模型对于优化Java应用程序、提高性能、避免内存泄漏和解决内存溢出问题至关重要。本文将以JDK8为例，详细解析JVM内存模型的各个组成部分。
Java类加载 自定义类加载器需要继承 java.lang.ClassLoader 类,这个类有两个核心方法// loadClass() 实现了双亲委派机制Class<?= null) {} else {sun// loadClass() 实现了双亲委派机制 protected Class <?
Netty底层探究 Netty中的编解码是通过ChannelHandler来实现的。编码器用于将应用程序数据转换为字节，以便在网络上传输。解码器则用于将接收到的字节转换为应用程序数据。这些编解码器通常被添加到ChannelPipeline中，以便在数据传输过程中自动进行编解码操作。这种方式可以帮助简化网络通信过程中的数据处理和转换。网络中数据都是基于0101的二进制字节传输的。.发送方需要将数据编码转化为二进制字节，接收方收到二进制字节，再解码成数据.在网络通信中，由于数据传输的不确定性，可能会导致粘包和拆包的问题.
Netty入门使用 NIO 的类库和 API 繁杂，使用起来比较麻烦，需要熟练掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等。开发工作量和难度都非常大，例如客户端面临断线重连、网络闪断、心跳处理、半包读写、网络拥塞和异常流的处理等。Netty 对 JDK 自带的 NIO 的 API 进行了良好的封装，解决了上述问题。此外，Netty 拥有高性能、吞吐量更高，延迟更低，减少资源消耗，最小化不必要的内存复制等优点。
搞懂BIO与NIO 1. 每个连接对应一个线程，导致线程数量随着连接数增加而增加，可能导致资源消耗过大。2. 读取和写入操作是阻塞的，可能导致性能瓶颈，特别是在大量并发连接的情况下。3. 适用于连接数较少且通信量不大的场景，但在高并发情况下性能表现不佳。NIO是Java中用于高性能I/O操作的一种机制。它提供了Channel和Buffer的抽象，以及Selector的多路复用能力，使得单个线程可以有效地管理多个通道的I/O操作。NIO相对于传统的I/O（即BIO）具有更高的并发性能和可扩展性，适用于需要处理大量连接的网络应用。
搞懂 三次握手四次挥手 三次握手用于建立连接，确保双方都愿意通信；四次挥手用于关闭连接，保证双方都能安全、可靠地关闭连接。在这些过程中，序列号、确认号、状态转换等都起到关键作用，确保了连接的可靠性和稳定性。
zookerper集群Leader选举 总体来说，这些队列和流程用于实现 ZooKeeper 集群中的 Leader 选举和消息传递机制。这是一个分布式系统中常见的模式，确保各个节点之间的通信和同步。可以通过下面zk集群启动的源码过程，加深zk集群的选举逻辑.
zookerper入门 ZooKeeper 是一个开源的分布式协调框架,主要用来解决分布式集群中应用系统的一致性问题.ZooKeeper本质上是一个分布式的小文件存储系统（Zookeeper=文件系统+监听机制）.提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。
Redis之常用架构 主从复制是简单的备份和读写分离模式，适用于基本的备份需求。哨兵模式在主从架构基础上提供了自动化的故障检测和转移。集群模式适用于处理大规模数据和高并发请求的情况，提供了自动化的分片和负载均衡。每种架构都有其优势和限制，选择合适的架构取决于应用需求、复杂性和可用性要求。在设计Redis架构时，需要根据具体情况综合考虑这些因素，并可能结合多种架构模式来达到最佳的性能、可用性和扩展性。
Mybaits拦截器实现水平分表 *** 表名*//*** 算法策略*/// 需要分表的table的Mapper接口1.Mapper文件问题老系统比较混乱，存在多表关联查询，有些Mapper.xml对象对应的sql不是唯一表。这里需要注意，因为注解是针对整个Mapper文件的，只要是上面的sql都会拦截。但是需要分表的sql都必须要有分表字段。需要避免不分表的sql走策略算法。最好将需要分表的表拆成单表，逻辑在代码里处理。2.分页插件pagehelper导致自定义插件无效。
数据库常用分库分表方案 分库分表是因应数据库处理大规模数据时所面临的挑战而出现的解决方案.数据库瓶颈不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）.分库分表水平分库1.根据容量（当前容量和增长量）评估分库或分表个数 .2.确定分库分表的key，尽量均匀.3.确定分库分表的规则4.迁移数据(一般双写)以上介绍了分库分表的一些理论知识，下一
分布式事务 / 2PC 小规模系统或需要简单事务处理的场景。不要求高性能和高可用性，可以接受同步阻塞的情况。// 3PC 对于对 2 PC 阻塞问题有所顾虑的场景，可以考虑使用 3 PC。对系统性能和可用性要求不高的一些应用。// TCC 对于需要更精细控制的业务场景，如金融交易、订单支付等。需要高可用和高性能，可以灵活处理事务逻辑的场景。// 事务消息 对分布式事务的一致性要求高，同时需要异步处理的场景。需要可靠消息传递和确保一致性的异步操作。
JDK8 ConcurrentHashMap 这里总结下 JDK 7 和 JDK 8 中的 ConcurrentHashMap的区别// 数据结构JDK7:Segment[] + HashEntry[] + 链表JDK8:Node[] + 链表 + 红黑树// 加锁机制JDK7:使用Segment分段锁，用的ReentrantLockJDK8:使用CAS操作和 synchronized 关键字// 扩容机制JDK7:每个Segment数组在元素达到一定数量时会进行扩容，即每个Segment独立扩容，不涉及整体扩容.
JDK7 ConcurrentHashMap JDK7 中的 ConcurrentHashMap 通过分段锁和哈希表的组合实现了高效的并发操作。每个 Segment 独立进行操作，通过减小锁的粒度来提高并发性能。下节我们来看JDK8中对ConcurrentHashMap又有哪些改进！！！
JDK8 HashMap 总体而言，JDK8的HashMap在JDK7的基础上进行了优化，引入了树形结构来优化链表的查询效率，提高了元素的检索速度，同时也保持了哈希表的基本特性。总结JDK7和JDK8种HashMap的区别。
关注
