1、传统io:
1、server端创建连接方法server.accept()、从连接中读取数据的方法inputStream.read(bytes),这两个方法都是阻塞的,表示如果这两个方法没有返回值时候,
线程就是一直在等待返回结果的,不能处理其他请求的。
2、一个线程同时只能为一个client的连接服务,如果这个连接不断开,这个线程就不能为别的client服务。这导致处理多个连接需要多个线程,线程的创建会消耗
内存,这样会消耗大量的内存,所以在处理多连接的场景中传统io是不适合的。
2、nio:
1、nio中的channel对应传统io中的socket
2、一个线程同时可以为多个client的连接服务,一个线程对应一个selector即一个线程借助一个selector来为多个连接服务。
3、selector.select()这个方法是阻塞的,如果有返回值,表示这个selector管理的连接中有一部分连接需要进行处理了,得到的是selectionkey的集合,根据selectionkey
就可以找到对应的连接,为这个连接进行相应的事件处理(读数据、创建连接),这个方法底层是c语言实现的。
1、selector.select()这个方法默认是阻塞的,也可以通过参数设置为不阻塞立刻返回结果的,关键他的read方法是不阻塞的,所以nio是非阻塞的io。
4、一个线程管理一个selector,一个selector管理多个selectionkey,一个selectionkey对应一个连接。
5、开发时候根据业务需要,比如读取到数据后在写数据给client,如果没有读取到数据可能就是client断开连接了,这时候就可以不需要写出数据了。
6、server监听一个端口,client建立连接,创建连接后得到对应的channel,把这个channel注册到一个selector上面,让这个selector管理这个channel的读取数据事件。
3、netty:
1、传统io是socket,nio是channel,netty是对nio的封装,让我们使用起来更简单。
2、netty的主要使用场景是基于tcp长连接实现进程之间的通信,比如大数据底层好多进程之间的通信都是使用的netty。
3、boss线程是管理线程,worker线程是工作线程,bootstrap是netty的启动类,启动类中指定了pipeline管道,管道可以看成一个拦截器链,可以添加多个handler进行
处理。不同handler进行不同的处理,比如decoder是处理上行数据,encoder是处理下行数据。
4、messageReceive方法中判断频次过高就可以通过channel把这个连接关闭掉,把client的ip计入黑名单,channelConnected方法中判断如果是黑名单的ip就不进行连接。
5、boss线程池中一个线程对应一个selector,这个selector负责一部分连接的创建。worker线程池中一个线程对应一个selector,这个selector负责一部分连接的读取
数据事件处理。
6、更确切的是一个Runnable任务对象有一个selector的成员变量,一个Runnable对应一个selector,一个线程对应一个Runnable任务,一个selector对应多个channel,
一个channel对应一个selectionkey。
3、线程池:
1、CachedThreadPool:带缓存的线程池,来了请求如果没有空闲线程,就会创建新的线程来处理请求,这样可能导致创建无限多的线程。
2、FixedThreadPool:固定大小的线程池,来了请求如果没有空闲线程,就会放入这个线程池对应的一个队列中,如果队列大小没限制,无限的请求可能导致无限大的队列。
3、线程池中一个线程对应一个队列,一个队列中可以存放多个runnable任务对象。多个线程之间执行的任务是并行,一个线程执行的任务是串行。
4、解决线程安全:
1、a线程通过在b线程的任务队列中添加任务的方式,让b线程去改变某个数据的值,而不是a、b两个线程都来修改这个数据的值,这样就很好的解决了线程安全问题,这是
一种思路。
2、boss、worker线程不都是直接修改channel数据的,而是boss线程创建一个任务丢给某个work线程去处理,这样间接的达到boss和worker都处理一个channel数据,但是
还没有线程安全问题。
3、如果任务对象是线程安全的,即可以多个线程同时操作数据也不会乱,这样多个线程操作这个任务对象时候不需要有阻塞等待,这个时候可以使用对象数组来存放任务
对象。
4、如果任务对象是线程不安全的,多个线程操作一个任务对象,这个数据可能会乱,这样多个线程不能同时操作一个任务,需要阻塞等待,这个时候可以使用对象池来
存放任务队列,类似连接池。
5、对象组中取出对象执行时候,是不需要把对象从数组中移除的(数组)。对象池取出对象执行时候,是需要把对象从池中移除使用完后在放回(队列)。
6、client实现自动重连server进行数据通信:本质是判断原来的channel不是active状态,就重新创建一个channel,利用新的channel跟server通信。
1、网关、设备、手机app作为client时候,为了提高用户体验,需要实现自动重连功能。
2、client可以给server发送心跳报文,server返回服务器的当前时间,如果心跳报文失败,client判断连接断开了,就可以进行重连了。
7、client可以实现多个连接,比如放到数组中,并且这多个连接都是可以自动重连的。这样的实例可以参见MultiClient类。
5、netty使用经验总结:
1、防止恶意攻击改进方案:
原来流程:client跟server创建后,发送登陆报文,成功走后面流程,不成功断开连接,这样存在的漏洞是,client跟server创建连接后不发送登陆报文,而是发
送其他一些报文,这样虽然不能进行后面业务逻辑操作,但是这个连接没有断开,还是占用服务器的资源。
改进流程:client跟server创建连接后,必须第一步就发送登陆报文,否则断开连接。思想是记录每个连接的第一个报文,判断是否是登陆报文。
2、server端可以指定一个handler,设置读超时、写超时、读写超时的时间,设置完后某个client连接到server,如果长时间没有读写操作,server端是可以感知到的,感
知到后可以踢用户下线,或者设置设备为下线状态,看业务需求进行处理。
1、server端长时间没有收到client的读写请求时候,server端就可以关闭channel释放资源,清除掉僵尸连接。
2、正常情况,client跟server端建立连接后,如果client端主动断开连接了,会发送通知给server端,server端channelclose(netty3)方法、inactive(netty5)
方法会被触发执行,这样我们可以在里面把channel关闭释放资源。
3、但是特殊情况,client突然断电或者断网,这样server端channelclose(netty3)方法、inactive(netty5)方法是不会触发的,就不会执行channel.close()了,
所以这种情况我们可以使用上面handler判断长时间没有跟client进行读写时候,就把这个channel关闭掉,这样达到释放资源效果更准确。
4、由client通知server释放资源,修改为server端自己检查如果长时间没交互,就关闭连接释放资源。
3、server端可以利用一个监听器,监听到给client端发送成功提示消息后,在关闭连接踢用户下线。
4、server端返回通常不是返回字符串,返回一个结果码,client根据提前约定的查找结果码代表什么意思。
6、对象序列化:
1、序列化:把对象转换成byte[]
2、利用protocol buff序列化和反序列化
1、自己编写.pro文件,利用他提供的工具根据.pro文件生成java类、和工具类
2、我们在项目中就可以使用这些工具类来进行序列化和反序列化了
3、比java自带的序列化得到的结果小很多,这样可以减少传输带宽,提高传输效率
3、java自带的ObjectStream进行序列化反序列化
3、把一个byte[]中的内容打印出来可以使用Arrays.toString(byte[])
7、分包粘包:
1、server端接收client端的报文数据,不知道哪个是一个完整的报文
2、解决办法1、可以使用特殊分隔符对报文进行分割 2、长度+数据的报文格式
3、自定义协议开发client和server端通信过程:
1、client构建request对象,利用利用requestEncoder转换成字节数组,发送给server
2、server收到byte[],利用requestDecoder解码得到request对象
3、server进行业务处理,构建response对象,利用responseEncoder得到byte[]返回给client
4、client得到byte[]利用responseDecoder解码得到response对象
4、缓冲区中的内容可能是多个报文的数据,这就产生了粘包问题,缓存区中取出的是一个报文的一部分,这就发生了分包现象
5、可以自定义一个Decoder类继承FrameDecoder,在里面处理封装成一个完整报文在传递给handler进行处理
6、报文格式如果只是长度+数据,这样可能被恶意攻击,发送很大内容的数据把服务器缓存撑爆,即socket字节流攻击
7、解决办法是:报文中必须还要增加报文头(也可以叫做包头),这样一个特殊的分隔符来判断报文的开始,这样遇到非法数据后,就可以丢弃非法数据,从后面
一个字节一个字节的查找包头,找到下一个报文的起始位置,把非法数据丢弃掉不处理,可能会损失一些真正报文,如果业务不允许,就要进行复杂的
代码处理。
8、decode方法中return null,表示数据为到全,等待数据到来。return一个对象表示解析出来了一个报文数据,传给下一个handler进行处理。
9、调用了buffer的read方法,指针就会后移,buffer.readableBytes()可读取的内容就会减少。
10、netty接收数据的思想:定义好报文的格式,把接收到的数据先放到一个缓冲字节数组中,先判断长度是否满足报文定义的基本长度才开始进行处理,字节数组
中内容太长表示恶意攻击,清空字节数组的内容,字节数组中的长度小于了报文定义的基本长度,又会回到起始位置等待接收新的数据,如果字节数组
的长度大于报文定义的基本长度,可读取的内容也不是太大,那么就开始读取包头,如果没找到就一个字节一个字节的略过,直到找到包头,顺序读取
协议规定的内容,读取真正数据时候如果长度不够,就return null等待数据到来后重新前面的逻辑。
11、netty简单理解:数据来了放入缓存,解析出一个报文就后传,解析不出来表示数据还没有到齐在缓存中等待剩余部分到来。所有没处理的报文都在缓冲区中
存放着,凑个了一个报文解析出来向后传递,缓冲区中的报文就减少一个。
8、利用netty开发中,encoder、decoder、handler的作用
1、接收到数据利用decoder可以把字节数组转换成对象
2、利用encoder把对象的各个部分顺序写出去,这样就可以保证发送出去的是相应的字节数组了
3、handler中收到的数据就是对象了,我们直接用来进行业务逻辑处理
4、decoder和handler是配合使用的,先经过decoder的处理,handler中就会拿到相应的结果进行处理了
5、如果使用的是DelimiterBasedFrameDecoder,那么handler中拿到的就是分割好的byte[]
6、如果使用的是自定义的RequestDecoder,那么handler中拿到的就是RequestDecoder中解析好的Request对象了
7、不管是client还是server端,都是decoder后得到数据handler中进行处理,业务处理完后,把返回对象encoder成byte[]写出去
9、一个消息在channel中是怎样在多个handler间进行流转的
1、encoder和decoder本质上也是handler
2、messageEvent进入管道后,会顺序查找哪些handler是可以处理这个event的,可以处理的就进行处理
3、这些handler是通过双向链表串联起来的
4、一个messageEvent经过一个handler处理后,可能产生一个或者多个event,这些event向后流转查看是否有相应的handler对他们进行处理
5、handler往下传递对象的方法是sendUpstream(event),如果是decoder他向后传递对象的方法就是return对象就可以了,decoder返回的什么类型的对象handler中
就可以进行相应的强转就可以使用了。
6、一个线程处理的一个handler对象,所以handler是线程安全的,可以使用他的成员变量int count来记录处理的次数,是没有并发线程安全问题的。
10、自定义注解的使用:
1、自定义注解标示到自己的业务类上面,比如模块注解、命令注解
2、把业务类交给spring管理,这样就可以利用spring的一个工具类(自定义Scanner实现BeanPostProcessor),实例化完bean后,解析bean上面的注解
3、如果发现bean上面有我们自定义的注解,并且bean的方法上面有自定义的注解,那么就把这个bean和他的method进行存储,这样springioc启动完成后
会把所有标记了注解的,bean、method构造成一个invoker对象,然后把这些invoker对象放到一个map中,根据业务要求map的结构如下:
Map<"模块标示",Map<"命令标示",invoker>> ,如果业务分多个模块了
Map<"命令标示",invoker>,如果业务没有分多个模块开发
4、接收报文解析出模块标示、命令标示,就可以从map中找到对应的invoker了,解析出的报文把参数传递过来,进行invoker调用就可以了。实现通信框架和业务的解耦。
5、根据bean找到字节码文件,然后找到类名,然后找到类上面的注解,然后找到类里面方法上面的注解。
11、netty3和netty4的主要区别:
netty3 netty4或5
ChannelBuffer ByteBuf
ChannelBuffers PooledByteBufAllocator(要注意使用完后释放buffer)或UnpooledByteBufAllocator或Unpooled
FrameDecoder ByteToMessageDecoder
OneToOneEncoder MessageToByteEncoder
messageReceive channelRead0(netty5里面是messageReceive)
12、使用自定义的业务线程池,避免worker线程处理业务产时间占用,导致worker线程池不能处理高并发的请求:
1、handler的channelRead方法得到request对象后,直接交给业务对象去处理,这样handler和serviceimpl对象中都使用的是worker线程
2、打印日志可以看出来
3、有高并发的client的请求时候,worker线程不能及时处理
4、解决办法就是增加公工作线程池,handler中的worker线程接收到request对象后,直接构建成runnable任务对象丢给工作线程池中的线程去处理
5、这样worker线程可以处理的client的qps就更高了
6、业务线程池的大小设置的是cpu核数*2,仿照netty中设置worker线程池大小设置的
7、上面是netty3的解决方案,netty4中可以自定义一个EventLoopGroup的业务线程池,这样处理业务的线程就不是worker线程了,思想是类似的。
8、netty4中使用EventLoopGroup的业务线程池,在addhandler时候指定即可。
9、这种方式比netty3中使用自定义的业务线程池,把runnable任务丢进去的方式要好,他可以做到一个channel即一个用户的多个请求是顺序处理的。
10、线程池中的每个线程都对应一个队列,使用EventLoopGroup的业务线程池这种方式他底层保证了,一个channel(一个用户)的请求放到一个线程池的队列中去处理
这样就保证了,肯定是一个线程来顺序处理这些请求的了。
11、本质是把一个用户的请求放到了一个线程对应的队列中去处理,netty3中自定义的线程池,可能是把一个用户的请求放到了不同线程的多个队列中,这样导致这些
请求的处理就不是顺序的了。
1、server端创建连接方法server.accept()、从连接中读取数据的方法inputStream.read(bytes),这两个方法都是阻塞的,表示如果这两个方法没有返回值时候,
线程就是一直在等待返回结果的,不能处理其他请求的。
2、一个线程同时只能为一个client的连接服务,如果这个连接不断开,这个线程就不能为别的client服务。这导致处理多个连接需要多个线程,线程的创建会消耗
内存,这样会消耗大量的内存,所以在处理多连接的场景中传统io是不适合的。
2、nio:
1、nio中的channel对应传统io中的socket
2、一个线程同时可以为多个client的连接服务,一个线程对应一个selector即一个线程借助一个selector来为多个连接服务。
3、selector.select()这个方法是阻塞的,如果有返回值,表示这个selector管理的连接中有一部分连接需要进行处理了,得到的是selectionkey的集合,根据selectionkey
就可以找到对应的连接,为这个连接进行相应的事件处理(读数据、创建连接),这个方法底层是c语言实现的。
1、selector.select()这个方法默认是阻塞的,也可以通过参数设置为不阻塞立刻返回结果的,关键他的read方法是不阻塞的,所以nio是非阻塞的io。
4、一个线程管理一个selector,一个selector管理多个selectionkey,一个selectionkey对应一个连接。
5、开发时候根据业务需要,比如读取到数据后在写数据给client,如果没有读取到数据可能就是client断开连接了,这时候就可以不需要写出数据了。
6、server监听一个端口,client建立连接,创建连接后得到对应的channel,把这个channel注册到一个selector上面,让这个selector管理这个channel的读取数据事件。
3、netty:
1、传统io是socket,nio是channel,netty是对nio的封装,让我们使用起来更简单。
2、netty的主要使用场景是基于tcp长连接实现进程之间的通信,比如大数据底层好多进程之间的通信都是使用的netty。
3、boss线程是管理线程,worker线程是工作线程,bootstrap是netty的启动类,启动类中指定了pipeline管道,管道可以看成一个拦截器链,可以添加多个handler进行
处理。不同handler进行不同的处理,比如decoder是处理上行数据,encoder是处理下行数据。
4、messageReceive方法中判断频次过高就可以通过channel把这个连接关闭掉,把client的ip计入黑名单,channelConnected方法中判断如果是黑名单的ip就不进行连接。
5、boss线程池中一个线程对应一个selector,这个selector负责一部分连接的创建。worker线程池中一个线程对应一个selector,这个selector负责一部分连接的读取
数据事件处理。
6、更确切的是一个Runnable任务对象有一个selector的成员变量,一个Runnable对应一个selector,一个线程对应一个Runnable任务,一个selector对应多个channel,
一个channel对应一个selectionkey。
3、线程池:
1、CachedThreadPool:带缓存的线程池,来了请求如果没有空闲线程,就会创建新的线程来处理请求,这样可能导致创建无限多的线程。
2、FixedThreadPool:固定大小的线程池,来了请求如果没有空闲线程,就会放入这个线程池对应的一个队列中,如果队列大小没限制,无限的请求可能导致无限大的队列。
3、线程池中一个线程对应一个队列,一个队列中可以存放多个runnable任务对象。多个线程之间执行的任务是并行,一个线程执行的任务是串行。
4、解决线程安全:
1、a线程通过在b线程的任务队列中添加任务的方式,让b线程去改变某个数据的值,而不是a、b两个线程都来修改这个数据的值,这样就很好的解决了线程安全问题,这是
一种思路。
2、boss、worker线程不都是直接修改channel数据的,而是boss线程创建一个任务丢给某个work线程去处理,这样间接的达到boss和worker都处理一个channel数据,但是
还没有线程安全问题。
3、如果任务对象是线程安全的,即可以多个线程同时操作数据也不会乱,这样多个线程操作这个任务对象时候不需要有阻塞等待,这个时候可以使用对象数组来存放任务
对象。
4、如果任务对象是线程不安全的,多个线程操作一个任务对象,这个数据可能会乱,这样多个线程不能同时操作一个任务,需要阻塞等待,这个时候可以使用对象池来
存放任务队列,类似连接池。
5、对象组中取出对象执行时候,是不需要把对象从数组中移除的(数组)。对象池取出对象执行时候,是需要把对象从池中移除使用完后在放回(队列)。
6、client实现自动重连server进行数据通信:本质是判断原来的channel不是active状态,就重新创建一个channel,利用新的channel跟server通信。
1、网关、设备、手机app作为client时候,为了提高用户体验,需要实现自动重连功能。
2、client可以给server发送心跳报文,server返回服务器的当前时间,如果心跳报文失败,client判断连接断开了,就可以进行重连了。
7、client可以实现多个连接,比如放到数组中,并且这多个连接都是可以自动重连的。这样的实例可以参见MultiClient类。
5、netty使用经验总结:
1、防止恶意攻击改进方案:
原来流程:client跟server创建后,发送登陆报文,成功走后面流程,不成功断开连接,这样存在的漏洞是,client跟server创建连接后不发送登陆报文,而是发
送其他一些报文,这样虽然不能进行后面业务逻辑操作,但是这个连接没有断开,还是占用服务器的资源。
改进流程:client跟server创建连接后,必须第一步就发送登陆报文,否则断开连接。思想是记录每个连接的第一个报文,判断是否是登陆报文。
2、server端可以指定一个handler,设置读超时、写超时、读写超时的时间,设置完后某个client连接到server,如果长时间没有读写操作,server端是可以感知到的,感
知到后可以踢用户下线,或者设置设备为下线状态,看业务需求进行处理。
1、server端长时间没有收到client的读写请求时候,server端就可以关闭channel释放资源,清除掉僵尸连接。
2、正常情况,client跟server端建立连接后,如果client端主动断开连接了,会发送通知给server端,server端channelclose(netty3)方法、inactive(netty5)
方法会被触发执行,这样我们可以在里面把channel关闭释放资源。
3、但是特殊情况,client突然断电或者断网,这样server端channelclose(netty3)方法、inactive(netty5)方法是不会触发的,就不会执行channel.close()了,
所以这种情况我们可以使用上面handler判断长时间没有跟client进行读写时候,就把这个channel关闭掉,这样达到释放资源效果更准确。
4、由client通知server释放资源,修改为server端自己检查如果长时间没交互,就关闭连接释放资源。
3、server端可以利用一个监听器,监听到给client端发送成功提示消息后,在关闭连接踢用户下线。
4、server端返回通常不是返回字符串,返回一个结果码,client根据提前约定的查找结果码代表什么意思。
6、对象序列化:
1、序列化:把对象转换成byte[]
2、利用protocol buff序列化和反序列化
1、自己编写.pro文件,利用他提供的工具根据.pro文件生成java类、和工具类
2、我们在项目中就可以使用这些工具类来进行序列化和反序列化了
3、比java自带的序列化得到的结果小很多,这样可以减少传输带宽,提高传输效率
3、java自带的ObjectStream进行序列化反序列化
3、把一个byte[]中的内容打印出来可以使用Arrays.toString(byte[])
7、分包粘包:
1、server端接收client端的报文数据,不知道哪个是一个完整的报文
2、解决办法1、可以使用特殊分隔符对报文进行分割 2、长度+数据的报文格式
3、自定义协议开发client和server端通信过程:
1、client构建request对象,利用利用requestEncoder转换成字节数组,发送给server
2、server收到byte[],利用requestDecoder解码得到request对象
3、server进行业务处理,构建response对象,利用responseEncoder得到byte[]返回给client
4、client得到byte[]利用responseDecoder解码得到response对象
4、缓冲区中的内容可能是多个报文的数据,这就产生了粘包问题,缓存区中取出的是一个报文的一部分,这就发生了分包现象
5、可以自定义一个Decoder类继承FrameDecoder,在里面处理封装成一个完整报文在传递给handler进行处理
6、报文格式如果只是长度+数据,这样可能被恶意攻击,发送很大内容的数据把服务器缓存撑爆,即socket字节流攻击
7、解决办法是:报文中必须还要增加报文头(也可以叫做包头),这样一个特殊的分隔符来判断报文的开始,这样遇到非法数据后,就可以丢弃非法数据,从后面
一个字节一个字节的查找包头,找到下一个报文的起始位置,把非法数据丢弃掉不处理,可能会损失一些真正报文,如果业务不允许,就要进行复杂的
代码处理。
8、decode方法中return null,表示数据为到全,等待数据到来。return一个对象表示解析出来了一个报文数据,传给下一个handler进行处理。
9、调用了buffer的read方法,指针就会后移,buffer.readableBytes()可读取的内容就会减少。
10、netty接收数据的思想:定义好报文的格式,把接收到的数据先放到一个缓冲字节数组中,先判断长度是否满足报文定义的基本长度才开始进行处理,字节数组
中内容太长表示恶意攻击,清空字节数组的内容,字节数组中的长度小于了报文定义的基本长度,又会回到起始位置等待接收新的数据,如果字节数组
的长度大于报文定义的基本长度,可读取的内容也不是太大,那么就开始读取包头,如果没找到就一个字节一个字节的略过,直到找到包头,顺序读取
协议规定的内容,读取真正数据时候如果长度不够,就return null等待数据到来后重新前面的逻辑。
11、netty简单理解:数据来了放入缓存,解析出一个报文就后传,解析不出来表示数据还没有到齐在缓存中等待剩余部分到来。所有没处理的报文都在缓冲区中
存放着,凑个了一个报文解析出来向后传递,缓冲区中的报文就减少一个。
8、利用netty开发中,encoder、decoder、handler的作用
1、接收到数据利用decoder可以把字节数组转换成对象
2、利用encoder把对象的各个部分顺序写出去,这样就可以保证发送出去的是相应的字节数组了
3、handler中收到的数据就是对象了,我们直接用来进行业务逻辑处理
4、decoder和handler是配合使用的,先经过decoder的处理,handler中就会拿到相应的结果进行处理了
5、如果使用的是DelimiterBasedFrameDecoder,那么handler中拿到的就是分割好的byte[]
6、如果使用的是自定义的RequestDecoder,那么handler中拿到的就是RequestDecoder中解析好的Request对象了
7、不管是client还是server端,都是decoder后得到数据handler中进行处理,业务处理完后,把返回对象encoder成byte[]写出去
9、一个消息在channel中是怎样在多个handler间进行流转的
1、encoder和decoder本质上也是handler
2、messageEvent进入管道后,会顺序查找哪些handler是可以处理这个event的,可以处理的就进行处理
3、这些handler是通过双向链表串联起来的
4、一个messageEvent经过一个handler处理后,可能产生一个或者多个event,这些event向后流转查看是否有相应的handler对他们进行处理
5、handler往下传递对象的方法是sendUpstream(event),如果是decoder他向后传递对象的方法就是return对象就可以了,decoder返回的什么类型的对象handler中
就可以进行相应的强转就可以使用了。
6、一个线程处理的一个handler对象,所以handler是线程安全的,可以使用他的成员变量int count来记录处理的次数,是没有并发线程安全问题的。
10、自定义注解的使用:
1、自定义注解标示到自己的业务类上面,比如模块注解、命令注解
2、把业务类交给spring管理,这样就可以利用spring的一个工具类(自定义Scanner实现BeanPostProcessor),实例化完bean后,解析bean上面的注解
3、如果发现bean上面有我们自定义的注解,并且bean的方法上面有自定义的注解,那么就把这个bean和他的method进行存储,这样springioc启动完成后
会把所有标记了注解的,bean、method构造成一个invoker对象,然后把这些invoker对象放到一个map中,根据业务要求map的结构如下:
Map<"模块标示",Map<"命令标示",invoker>> ,如果业务分多个模块了
Map<"命令标示",invoker>,如果业务没有分多个模块开发
4、接收报文解析出模块标示、命令标示,就可以从map中找到对应的invoker了,解析出的报文把参数传递过来,进行invoker调用就可以了。实现通信框架和业务的解耦。
5、根据bean找到字节码文件,然后找到类名,然后找到类上面的注解,然后找到类里面方法上面的注解。
11、netty3和netty4的主要区别:
netty3 netty4或5
ChannelBuffer ByteBuf
ChannelBuffers PooledByteBufAllocator(要注意使用完后释放buffer)或UnpooledByteBufAllocator或Unpooled
FrameDecoder ByteToMessageDecoder
OneToOneEncoder MessageToByteEncoder
messageReceive channelRead0(netty5里面是messageReceive)
12、使用自定义的业务线程池,避免worker线程处理业务产时间占用,导致worker线程池不能处理高并发的请求:
1、handler的channelRead方法得到request对象后,直接交给业务对象去处理,这样handler和serviceimpl对象中都使用的是worker线程
2、打印日志可以看出来
3、有高并发的client的请求时候,worker线程不能及时处理
4、解决办法就是增加公工作线程池,handler中的worker线程接收到request对象后,直接构建成runnable任务对象丢给工作线程池中的线程去处理
5、这样worker线程可以处理的client的qps就更高了
6、业务线程池的大小设置的是cpu核数*2,仿照netty中设置worker线程池大小设置的
7、上面是netty3的解决方案,netty4中可以自定义一个EventLoopGroup的业务线程池,这样处理业务的线程就不是worker线程了,思想是类似的。
8、netty4中使用EventLoopGroup的业务线程池,在addhandler时候指定即可。
9、这种方式比netty3中使用自定义的业务线程池,把runnable任务丢进去的方式要好,他可以做到一个channel即一个用户的多个请求是顺序处理的。
10、线程池中的每个线程都对应一个队列,使用EventLoopGroup的业务线程池这种方式他底层保证了,一个channel(一个用户)的请求放到一个线程池的队列中去处理
这样就保证了,肯定是一个线程来顺序处理这些请求的了。
11、本质是把一个用户的请求放到了一个线程对应的队列中去处理,netty3中自定义的线程池,可能是把一个用户的请求放到了不同线程的多个队列中,这样导致这些
请求的处理就不是顺序的了。
12、一个用户的请求让一个业务线程去处理,一个线程可能处理多个用户请求的,不是让多个去处理。
![](https://i-blog.csdnimg.cn/blog_migrate/f45bee0f0aa6aa8617b1b22fba25d61d.png)
![](https://i-blog.csdnimg.cn/blog_migrate/6744baed19fdcbc0ddd56a062bb1e167.png)