Netty

JDK中的Future特性 在介绍Netty的ChannelFuture之前，我们先来看看JDK中的Future是如何实现的。总的来说就是任务提交的时候会使用装饰器模式，将任务包装成一个FutureTask。当执行器执行该Task的时候，不仅仅会执行用户提交的任务，还会执行装饰器添加的额外操作，例如在执行之前记录当前执行线程、执行完成后将任务结果保存在FutureTask对象内部等。 Thread runner => 装饰器添加的，在执行任务之前，会在对象内保存当前执行线程的引用，用于中断任务执行 Object outcome => 任务执行结果（返回值或异常对象），任务执行完成后会将结果set到此对象的outcome，后续可通过Future的get接口取出 Callable<V> callble => 用户提交的实际任务 WaitNode waiters => 用于保存等待线程，任务完成后会唤醒这些线程 详细请看本人过去整理的随笔： 揭开Future的神秘面纱——任务取消 揭开Future的神秘面纱——任务执行 揭开Future的神秘面纱——结果获取 Netty中的ChannelFuture ChannelFuture是在Future基础上的完善，它支持添加监听器，在任务完成后自动执行相关操作。 这个其实就是观察者模式，个人认为就是在前面的C部分添加监听的方法调用

首先自我介绍，非985，非211学校，主要从事Java后台开发，大一至现在做过两个项目（都不深），有一段去小公司的实习经历，今年刚到学校开始准备实习，陆续投了小米（我是米粉），阿里，华为，腾讯，京东，网易，今日头条等一系列互联网公司，小米，腾讯，今日头条挂一面，网易笔试过了和华为冲突了，去华为面试了，只拿到了阿里的java后台offer,华为应该算是口头offer吧（不过据说城里套路深，有可能是面试官诈你）,然后其他几家公司就不打算去面试了。 小米面试 小米是最早的，向来重视算法出名。 准时电话打过来，首先自我介绍，然后倒着输出链表元素（压入占输出），然后问如果要修改链表元素呢（也就是3个指针翻转链表了），然后让手写链表倒数第k个数（两个指针跑，一个先跑k步，后面一个再跑），写好后发邮件给他，老实说以前面试都是说一说算法就行，第一次这样写代码发过去，有点紧张，哆哆嗦嗦打开eclipse写完了发过去。 第二题:给定一个字符串如果某个字符是? 后面可以表示任意多个字符，如果是.说明可以表示一个字符，现在给定两个序列，问第二个能否符合第一个序列,卡住了，想了个递归发过去了。 第三题:设计红包算法。这个想想不是简单么，每一个红包随机啊，最后一个总数减就是了，后来面试官提醒必须至少保证每一个红包为0.01，然后改成先每一个都放0.01，再随机，估计有更好的方法。 你还有什么想说的：

出处： 那些惊艳的算法们（三）—— 时间轮 从定时任务说起 　　自然界中定时任务无处不在，太阳每天东升西落，候鸟的迁徙，树木的年轮，人们每天按时上班，每个月按时发工资、交房租，四季轮换，潮涨潮落，等等，从某种意义上说，都可以认为是定时任务。 大概很少有人想过，这些“定时”是怎样做到的。当然，计算机领域的同学们可能对此比较熟悉，毕竟工作中的定时任务也是无处不在的：每天凌晨更新一波数据库，每天9点发一波邮件，每隔10秒钟抢一次火车票。。。 　　至于怎么实现的？很简单啊，操作系统的crontab，spring框架的quartz,实在不行Java自带的ScheduledThreadPool都可以很方便的做到定时任务的管理调度。 　　当你熟练的敲下“* * 9 * * ?”等着神奇的事情发生时，你是否想过背后的“玄机”？ 初识时间轮 大概去年的时候，业务需要实现一个时间调度的工具，定时生成报表，同组的哥们儿想了一个取巧的办法： 　　1. 启动时从DB读取cron表达式解析，算出该任务下次执行的时间。 　　2. 下次执行的时间 - 当前时间 = 时间差。 　　3. 向ScheduleThreadPool线程池中提交一个延迟上面算出来的时间差的执行的任务。 　　4. 任务执行时，算一下这个任务下次执行的时间，算时间差，提交到线程池。 　　5. 当任务需要取消时

没有找到这个类？ 6.2.3也没有，换成老师的5.5.2就可以了。。 6.x之后是使用更高效的netty4做异步通信的。 gradle项目中引入，注意版本哦 compile 'org.elasticsearch.plugin:transport-netty4-client:6.2.4' 来源： oschina 链接： https://my.oschina.net/u/4400622/blog/4259160

昨天整理旧代码的时候，发现了一个线程池创建单例的工具类，写法如下: public class ThreadPoolUtil { /** * 使用有界队列，避免OOM */ private static ExecutorService consumerExecutor; private ThreadPoolUtil() { } /** * 获取线程池实例 * * @return 线程池对象 */ public static ExecutorService getInstance() { if (null == consumerExecutor) { System.out.println(System.currentTimeMillis() + " 初始化:" + Thread.currentThread().getName()); consumerExecutor = new ThreadPoolExecutor(15, 20, 5, TimeUnit.SECONDS, new ArrayBlockingQueue<>(512), new ThreadPoolExecutor.DiscardPolicy()); } return consumerExecutor; } } 乍一看确实没有问题，在非多线程的环境下，运行也是良好，但是实际情况是，在多线程环境下，这段代码会重复初始化多次

Netty 系列（三）Netty 入门 Netty 是一个提供异步事件驱动的网络应用框架，用以快速开发高性能、高可靠性的网络服务器和客户端程序。更多请参考： Netty Github 和 Netty中文入门 。 一、获得 Netty 可以通过 Maven 安装Netty。查看 Netty之HelloWorld 快速入门， 更多API <dependency> <groupId>io.netty</groupId> <artifactId>netty-all</artifactId> <version>5.0.0.Alpha2</version> </dependency> 二、Netty 服务端开发 现在让我们从服务端的处理器的实现开始，处理器是由 Netty 生成用来处理 I/O 事件的。 public class ServerHandler extends ChannelHandlerAdapter { // (1) @Override public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { // (2) //1. 接收客户端的请求数据 ByteBuf buf = (ByteBuf)msg; byte[] data = new byte[buf.readableBytes

引言 前面我们介绍了网络一些基本的概念，虽然说这些很难吧，但是至少要做到理解吧。有了之前的基础，我们来正式揭开Netty这神秘的面纱就会简单很多。 服务端 public class PrintServer { public void bind(int port) throws Exception { EventLoopGroup bossGroup = new NioEventLoopGroup(); //1 EventLoopGroup workerGroup = new NioEventLoopGroup(); //2 try { ServerBootstrap b = new ServerBootstrap(); //3 b.group(bossGroup, workerGroup) //4 .channel(NioServerSocketChannel.class) //5 .option(ChannelOption.SO_BACKLOG, 1024) //6 .childHandler(new ChannelInitializer<SocketChannel>() { //7 @Override protected void initChannel(SocketChannel ch) throws Exception { ch.pipeline().addLast(new

我前几天才搞懂为啥是3次握手。。 而不是2次或者4次？ 有一个知识点是： 服务器端的socket底层是2个队列： 1个是正在连接的socket。 1个是连接上的客户端socket 第一次是: 客户端向服务器发送ack，表示：我要连接了，这时服务器接收到ack后，放到第一个队列中，记录下：这个socket正在发送ack要连接 第二次是：服务器会送ack，告诉服务器，咱俩能连上 第三次是：客户端发送ack，然后服务器收到后，将从第一个队列中移除，放到第二个队列中，表明这个服务器socket真正表明客户端的socket连上了 所以：不是2次，也不是4次。 就是3次 服务器端的socket： 第1个队列都是：正在发送ack，握手没完成的客户端socket 第二个队列中的，都是连接上的客户端socket 之所以引出这个问题是因为： 为什么netty要设计一个BossGroup，一个WorkerGroup 难道一个EventLoopGroup就不行吗？ 这个原因就是因为考虑到服务器端Socket真实的情况是2个队列 来源： oschina 链接： https://my.oschina.net/u/4345306/blog/4258289

<font size=3 face="黑体" > 疯狂创客圈 Java 高并发【 亿级流量聊天室实战】实战系列 【 博客园总入口 】</font > <font size=3 face="黑体" > 架构师成长+面试必备之 高并发基础书籍 【 Netty Zookeeper Redis 高并发实战 】</font > 疯狂创客圈 高并发 环境 视频，陆续上线： Windows Redis 安装（带视频） Linux Redis 安装（带视频） Windows Zookeeper 安装（带视频） Linux Zookeeper 安装（带视频） Linux RabbitMQ 安装（带视频） 小视频和部分工具 百度网盘链接，请参见 疯狂创客圈 高并发社群 博客 第一步： 准备 Redis桌面管理工具 推荐使用的桌面管理工具：Redis Desktop Manager 下载 Redis Desktop Manager 下载地址为 https://redisdesktop.com/download 疯狂创客圈网盘，已经有下载好的版本 安装 Redis Desktop Manager 下载到本地后，一路点击安装完成即可。 比较傻瓜式。 第二步： 下载Windows 版本的Redis 1， redis官方下载地址： https://redis.io/download， redis 64位下载地址

Netty 与三种 I/O 模式 经典的三种 I/O 模式 生活场景： 当我们去饭店吃饭时： 食堂排队打饭模式：排队在窗口，打好才走； 点单/等待被叫模式：等待被叫，好了自己去端； 包厢模式：点单后菜直接被端上桌。 Netty 对三种 I/O 模式的支持 为什么 Netty 仅支持 NIO 了？ 为什么 Netty 有多种 NIO 实现？ 通用的 NIO 实现（Common）在 Linux 下也是使用 epoll，为什么自己单独实现？ 实现的更好！ NIO 暴露了更多的可控参数，例如： JDK 的 NIO 默认实现是水平触发。 Netty 是边缘触发（默认）和水平触发可切换。 Netty 实现的垃圾回收更少、性能更好。 NIO 一定优于 BIO 吗？ BIO 代码简单。 特定场景：连接数少，并发度低，BIO 性能不输 NIO。 来源： oschina 链接： https://my.oschina.net/u/4370811/blog/4258262