最近在使用netty的时候突然碰到这样的一个警告:
2010-8-11 12:20:28 org.jboss.netty.util.internal.SharedResourceMisuseDetector
警告: You are creating too many MemoryAwareThreadPoolExecutor instances. MemoryAwareThreadPoolExecutor is a shared resource that must be reused across the application, so that only a few instances are created.
2010-8-11 12:20:28 org.jboss.netty.util.internal.SharedResourceMisuseDetector
警告: You are creating too many HashedWheelTimer instances. HashedWheelTimer is a shared resource that must be reused across the application, so that only a few instances are created.
说的是我在使用
MemoryAwareThreadPoolExecutor和HashedWheelTimer
的时候创造了太多的实例.后来一看源码才发现问题所在!这两个貌似都是线程池的对象,在各自的构造方法里面,每实例一个对象就会使各自SharedResourceMisuseDetector(滥用共享资源探测器)加一.当超过256的时候就报警了!
private static final SharedResourceMisuseDetector misuseDetector =
new SharedResourceMisuseDetector(MemoryAwareThreadPoolExecutor.class);
.....
// Misuse check
misuseDetector.increase();
后来再查看HashedWheelTimer的源代码中还发现了这样的提示:
<h3>Do not create many instances.</h3>
*
* {@link HashedWheelTimer} creates a new thread whenever it is instantiated and
* started. Therefore, you should make sure to create only one instance and
* share it across your application. One of the common mistakes, that makes
* your application unresponsive, is to create a new instance in
* {@link ChannelPipelineFactory}, which results in the creation of a new thread
* for every connection.
大致就说不要创建太多的实例
之前我是这样写的
public class ServerPipelineFactory implements ChannelPipelineFactory {
...
@Override
public ChannelPipeline getPipeline() throws Exception {
ChannelPipeline pipeline = pipeline();
pipeline.addLast("executor", new ExecutionHandler(new OrderedMemoryAwareThreadPoolExecutor(16, 1048576, 1048576)));
pipeline.addLast("timeout", new ReadTimeoutHandler(new HashedWheelTimer(), 10));
这样以来每个channel获取PipelineFactory的时候都会重新实例MemoryAwareThreadPoolExecutor和HashedWheelTimer,
当连接一多的时候就报警了!
根据这个提示我修改了ServerPipelineFactory,把他们做出单例的引用
public class ServerPipelineFactory implements ChannelPipelineFactory {
...
static OrderedMemoryAwareThreadPoolExecutor e = new OrderedMemoryAwareThreadPoolExecutor(16, 0, 0);
static HashedWheelTimer hashedWheelTimer = new HashedWheelTimer();
static ExecutionHandler executionHandler = new ExecutionHandler(e);
@Override
public ChannelPipeline getPipeline() throws Exception {
ChannelPipeline pipeline = pipeline();
pipeline.addLast("executor", executionHandler );
pipeline.addLast("timeout", new ReadTimeoutHandler(hashedWheelTimer, 10));
这样就不会再有SharedResourceMisuseDetector的警告了!
分享到:
相关推荐
84_Netty引用计数注意事项与内存泄露检测方式;85_Netty编解码器剖析与入站出站处理器详解;86_Netty自定义编解码器与TCP粘包拆包问题;87_Netty编解码器执行流程深入分析;88_ReplayingDecoder源码分析与特性解读;...
84_Netty引用计数注意事项与内存泄露检测方式 85_Netty编解码器剖析与入站出站处理器详解 86_Netty自定义编解码器与TCP粘包拆包问题 87_Netty编解码器执行流程深入分析 88_ReplayingDecoder源码分析与特性解读 89_...
第84讲:Netty引用计数注意事项与内存泄露检测方式 第85讲:Netty编解码器剖析与入站出站处理器详解 第86讲:Netty自定义编解码器与TCP粘包拆包问题 第87讲:Netty编解码器执行流程深入分析 第88讲:...
Netty引用计数的实现机制与自旋锁的使用技巧 82_Netty引用计数原子更新揭秘与AtomicIntegerFieldUpdater深度剖析 83_AtomicIntegerFieldUpdater实例演练与volatile关键字分析 84_Netty引用计数注意事项与内存泄露...
基本上,您可以只在通道处理程序中实现自己的业务,然后该库将为您完成所有肮脏的工作(特定于平台的注意事项,事件传送和处理,基本内存优化等)。 即使您只有很少的相应知识背景,您也可以编写基于http / https,...
项目注意事项netty 的版本修改为 4.1.25.Final,注意有两个 pom 文件,确认内层的 netty 版本为最新版本修改 etcd 客户端的版本,去掉原先的 exclude <dependency> <groupId>...> consumer-agent 固定请求方法为 http,...
项目注意事项 netty 的版本修改为 4.1.25.Final,注意有两个 pom 文件,确认内层的 netty 版本为最新版本 修改 etcd 客户端的版本,去掉原先的 exclude <groupId>com.coreos</groupId> <artifactId>jetcd-core ...
Spring使用注意事项 Spring验证Validation SpringBoot 开发知识 相关技术名词 开发技术框架工具整理 架构知识 开发过程注意事项整理 常用开发技巧 数据库 数据库基础知识 分库分表概念 数据库最佳实践 服务器运维 ...
注意事项 假定是类似下面的部署结构: nginx -> tomcat1 -> tomcat2 -> tomcat3 则nginx最好配置为sticky session。推荐淘宝的tengine 的session sticky模块: 或者这个项目: 因为后端的Session共享存储并不能锁...
│ Java面试题84:项目流程和业务注意事项.mp4 │ 面试必问-Mysql索引背后的故事 │ ├─java面试专属 │ ├─1.面试必考之HashMap源码分析与实现 │ │ 1.面试必考之HashMap源码分析与实现.mp4 │ │ │ ├─2....
java多线程tcp socket server源码 ...--(编写代码过程中的一些最佳实践,注意事项。现在已经出第二版了,增加了lambada的内容) JAVA网络编程 第4版 --(BIO socket编程,现在基本不用了) 性能优化 Java性