搜索
高级检索
高级搜索
书       名 :
著       者 :
出  版  社 :
I  S  B  N:
出版时间 :
Netty 4核心原理与手写RPC框架实战
0.00     定价 ¥ 108.00
浙江图书馆
  • ISBN:
    9787121385063
  • 作      者:
    谭勇德(Tom)
  • 出 版 社 :
    电子工业出版社
  • 出版日期:
    2020-04-01
收藏
编辑推荐

★ 《Spring 5核心原理与30个类手写实战》作者全新力作

★ 集作者多年实战及授课经验与学员踩坑经验总结之大成

★ 基于Netty 4,学习Dubbo、Spring Cloud等分布式技术基础必备

★ 全网创新“手写源码学习法”,让学习源码更高效

★ 提供基于Netty手写RPC框架、手写消息推送系统实战案例

★ 快速掌握Bootstrap、EventLoop、Pipeline、ByteBuf等核心技术

★ 深度剖析Netty的原理与特性,让学习Netty变得轻松易上手

★ 实用性强,是一本面向Netty应用者不可多得的实战类好书

★ 既可作为Netty应用实战指导书,又可作为日常学习工具书

 

让30W+学员受益的“手写源码学习法”开创者

影响100W+程序员的“Java架构师成长路径”制定人   

“手写Spring”畅销书作者

全新力作 

 

首发Netty 4版本的分布式通信技术必备图书

从网络通信硬件到Java I/O核心原理

从实战到面试一应俱全


一本书读懂Netty 4分布式通信技术!



展开
作者简介

谭勇德(Tom)

10余年Java开发经验。

咕泡学院联合创始人。

著有畅销书《Spring 5核心原理与30个类手写实战》。

在大型IT公司担任过CTO、系统架构师。

精通Java、JS、CSS、AS、PHP等;负责过多个大型分布式系统的微服务架构的技术改造;多年来对Netty框架有深入研究及独特见解;开发过多套企业内部UI框架和ORM框架;热衷于分享经验,共同进步。

格言:不只做一个技术者,更要做一个思考者。


展开
内容介绍

《Netty 4核心原理与手写RPC框架实战》首先从硬件层面深入分析网络通信原理,结合Java对网络I/O的API实现,将理论与实践串联起来,帮助大家透彻理解网络通信的起源,然后介绍Netty产生的背景并基于Netty手写Tomcat和RPC框架,帮助大家初步了解Netty的作用,接着分析Netty的核心原理和核心组件,基于Netty手写一个消息推送系统并进行性能调优,最后介绍设计模式在Netty中的应用和经典的面试题分析。

 

如果你想深入了解网络通信原理,

如果你还不知道Netty能做什么,

如果你想深入了解Netty的实现原理,

如果你看源码找不到入口,无从下手,

如果你想了解设计模式在Netty中的应用,

本书都能帮到你。


展开
精彩书评

Netty是当今互联网通信必备的底层技术,本书从硬件入手,深刻剖析网络通信原理,掌握本书中的知识是你学习其他互联网技术必备的前置条件。

                                                                                    James,咕泡学院联合创始人

                                                                                   

本书结合多年的授课经验和学员的踩坑经验整理而成,是学习分布式技术不可或缺的实战书籍。

                                                                                      Mic,咕泡学院联合创始人

 


展开
精彩书摘


7.2.7  Netty解决JDK空轮询Bug

大家应该早就听说过臭名昭著的Java NIO epoll的Bug,它会导致Selector空轮询,最终导致CPU使用率达到100%。官方声称JDK 1.6的update18修复了该问题,但是直到JDK 1.7该问题仍旧存在,只不过该Bug发生概率降低了一些而已,并没有被根本解决。出现此Bug是因为当Selector轮询结果为空时,没有进行wakeup或对新消息及时进行处理,导致发生了空轮询,CPU使用率达到了100%。我们来看一下这个问题在issue中的原始描述。

This is an issue with poll (and epoll) on Linux. If a file descriptor for a connected socket is polled with a request event mask of 0, and if the connection is abruptly terminated (RST) then the poll wakes up with the POLLHUP (and maybe POLLERR) bit set in the returned event set. The implication of this behaviour is that Selector will wakeup and as the interest set for the SocketChannel is 0 it means there aren't any selected events and the select method returns 0.

具体解释为:在部分Linux Kernel 2.6中,poll和epoll对于突然中断的Socket连接会对返回的EventSet事件集合置为POLLHUP,也可能是POLLERR,EventSet事件集合发生了变化,这就可能导致Selector会被唤醒。

这是与操作系统机制有关系的,JDK虽然仅仅是一个兼容各个操作系统平台的软件,但遗憾的是在JDK 5和JDK 6最初的版本中,这个问题并没有得到解决,而将这个“帽子”抛给了操作系统方,这就是这个Bug一直到2013年才最终修复的原因。

在Netty中最终的解决办法是:创建一个新的Selector,将可用事件重新注册到新的Selector中来终止空轮询。我们来回顾一下事件轮询的关键代码。

protected void run() {

        for (;;) {

switch (selectStrategy.calculateStrategy(selectNowSupplier, hasTasks())) {

                    case SelectStrategy.CONTINUE:

                        continue;

                    case SelectStrategy.SELECT:

                        select(wakenUp.getAndSet(false));

//省略select的唤醒逻辑

                    default:

                }

 

               //事件轮询处理逻辑

        }

}

前面我们提到select()方法解决了JDK空轮询的Bug,那么它到底是如何解决的呢?下面我们来一探究竟,先来看一下select()方法的源码。

public final class NioEventLoop extends SingleThreadEventLoop {

 

...

 

int selectorAutoRebuildThreshold = SystemPropertyUtil.getInt("io.netty. selectorAutoRebuildThreshold", 512);

//省略判断代码

        SELECTOR_AUTO_REBUILD_THRESHOLD = selectorAutoRebuildThreshold;

...

private void select(boolean oldWakenUp) throws IOException {

       Selector selector = this.selector;

   long currentTimeNanos = System.nanoTime();

   for (;;) {

         //省略非关键代码

    long timeoutMillis = (selectDeadLineNanos - currentTimeNanos + 500000L) / 1000000L;

             int selectedKeys = selector.select(timeoutMillis);

             selectCnt ++;

 

             //省略非关键代码

 

            long time = System.nanoTime();

            if (time - TimeUnit.MILLISECONDS.toNanos(timeoutMillis) >= currentTimeNanos) {

                 // timeoutMillis elapsed without anything selected.

                 selectCnt = 1;

            } else if (SELECTOR_AUTO_REBUILD_THRESHOLD > 0 &&

 selectCnt >= SELECTOR_AUTO_REBUILD_THRESHOLD) {

                    //日志打印代码

 

                    rebuildSelector();

                    selector = this.selector;

 

                    // Select again to populate selectedKeys.

                    selector.selectNow();

                    selectCnt = 1;

                    break;

                }

 

                currentTimeNanos = time;

            }

 

       //省略非关键代码

  }

}

    ...

}

从上面的代码中可以看出,Selector 每一次轮询都计数 selectCnt++,开始轮询会将系统时间戳赋值给timeoutMillis,轮询完成后再将系统时间戳赋值给time,这两个时间会有一个时间差,而这个时间差就是每次轮询所消耗的时间。从上面的逻辑可以看出,如果每次轮询消耗的时间为0s,且重复次数超过512次,则调用rebuildSelector()方法,即重构Selector,具体实现代码如下。

public void rebuildSelector() {

        //省略判断语句

        rebuildSelector0();

    }

 

    private void rebuildSelector0() {

        final Selector oldSelector = selector;

        final SelectorTuple newSelectorTuple;

 

   newSelectorTuple = openSelector();

       //省略非关键代码

 

        // Register all channels to the new Selector.

        int nChannels = 0;

        for (SelectionKey key: oldSelector.keys()) {

           //省略非关键代码和异常处理

                key.cancel();

                SelectionKey newKey = key.channel().register(newSelectorTuple.unwrappedSelector, interestOps, a);

                

        }

 

        //省略非关键代码

    }

实际上,在rebuildSelector()方法中,主要做了以下三件事情。

(1)创建一个新的Selector。

(2)将原来Selector中注册的事件全部取消。

(3)将可用事件重新注册到新的Selector,并激活。

就这样,Netty完美解决了JDK的空轮询Bug。看到这里,是不是感觉没那么神秘了?


展开
目录



展开
加入书架成功!
收藏图书成功!
我知道了(3)
发表书评
读者登录

温馨提示:请使用浙江图书馆的读者帐号和密码进行登录

点击获取验证码
登录