面试官：为什么不建议用Executors创建线程池？
面试官心理剖析 面试官问为什么不建议直接使用Executors创建线程池，这个问题背后隐藏着对候选人在并发编程和线程池管理方面的理解和经验的考察。 考察对并发编程的理解：面试官想知道候选人是否明白线程池在并发编程中的作用，以及不当使用线程池可能带来的问题。通过询问对Executors的看法，面试官可
记一次完整的JVM堆外内存泄漏故障排查记录
故障描述 像是Java进程出现了内存泄漏的情况，但我们的堆内存限制为4G。由于内存占用超过了4G，可以初步判断是JVM堆外内存泄漏。 确认了下当时服务进程的启动配置： -Xms4g -Xmx4g -Xmn2g -Xss1024K -XX:PermSize=256m -XX:MaxPermSize=5
消息队列总结（精华版）
导读 为什么使用消息队列？ 消息队列有什么优点和缺点？ Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 为什么使用消息队列 消息队列作为一种重要的中间件技术，在实际项目中有着广泛的应用场景。通过解耦、异步和削峰等手段，我们可以有效解决系统中遇到的多
JVM内存泄露、内存溢出
内存泄露 指程序中动态分配内存给一些临时对象，但是对象不会被 GC 所回收，它始终占用内存。即被分配的对象可达但已无用。 内存溢出 指程序运行过程中无法申请到足够的内存而导致的一种错误。内存溢出通常发生于 OLD 段或 Perm 段垃圾回收后，仍然无内存空间容纳新的 Java 对象的情况。 从定义上
Netty 源码分析之环境搭建
代码下载 首先到 Netty 的 Github 仓库 中, 点击右边绿色的按钮: 拷贝 git 地址: git@github.com:netty/netty.g
Netty 源码分析之 Bootstrap(客户端)
这一章是 Netty 源码分析系列的第一章, 打算在这一章中, 展示一下 Netty 的客户端和服务端的初始化和启动的流程, 给读者一个对 Netty 源码有一个大致的框架上的认识, 而不会深入每个功能模块. 本章会从 Bootstrap/ServerBootstrap 类 入手, 分析 Netty
Netty 源码分析之 Bootstrap(服务端)
服务器端 在分析客户端的代码时, 已经对 Bootstrap 启动 Netty 有了一个大致的认识, 那么接下来分析服务器端时, 就会相对简单一些了. 首先还是来看一下服务器端的启动代码: public final class EchoServer {
static final boole
Netty 源码分析之 ChannelPipeline(一)
前言 这篇是 Netty 源码分析 的第二篇, 在这篇文章中, 会为读者详细地分析 Netty 中的 ChannelPipeline 机制. Channel 与 ChannelPipeline 相信大家都知道了, 在 Netty 中每个 Channel 都有且仅有一个 ChannelPipeline
Netty 源码分析之 ChannelPipeline(二)
ChannelHandler 的名字 我们注意到, pipeline.addXXX 都有一个重载的方法, 例如 addLast, 它有一个重载的版本是: ChannelPipeline addLast(String name, ChannelHandler handler);
第一个参数指定了所添
Netty 源码分析之 EventLoop
简述 这一章是 Netty 源码分析 的第三章, 我将在这一章中大家一起探究一下 Netty 的 EventLoop 的底层原理, 让大家对 Netty 的线程模型有更加深入的了解. NioEventLoopGroup 在 Netty 源码分析之 Bootstrap (客户端) 章节中我们已经知道了
Netty 源码分析之ByteBuf
ByteBuf与ByteBuffer 我们在Netty 源码分析之Java NIO已经详细了解了NIO Buffer。这里先回忆下NIO Buffer的一些特性： ByteBuffer底层实现包含四个关键字段，并满足大小关系：mark <= position <= limit <= capacity
Netty 源码分析之 Promise 与 Future
Future和Promise的关系 Netty内部的io.netty.util.concurrent.Future 继承自java.util.concurrent.Future，而Promise是前者的一个特殊实现。 Java原生Future Java并发编程包下提供了Future接口。Future
Netty 源码分析之TCP粘包和拆包
一、基本介绍 1、TCP 是面向连接的，面向流的，提供高可靠性服务。收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发给接收端的包，更有效的发给对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据库，然后进行封包。这样做虽然提高了
Netty 源码分析之TCP粘包和拆包解决方案
一、解决方案 1、使用 自定义协议 + 编解码器 来解决 2、关键就是要解决 服务器端每次读取数据长度的问题，这个问题解决，就不会出现服务器多读或少读数据的问题，从而避免了 TCP粘包和拆包 二、应用实例 1、要求客户端发送 5 个 Message 对象，客户端每次发送一个 Message 对象 2
Netty 源码分析之Handler
回忆handler 链式结构 我们先来回忆下在Netty 源码分析之 ChannelPipeline(一) 提到过来的handler链式结构： handler分为实现ChannelInboundHandler接口的入站处理器和实现ChannelOutboundHandler接口的出站处理器； han