zrlw
zrlw
用新版sync试一下,之前版本的分组名称可能是当做命名空间了
可以写个sql脚本直接插入数据库,里面的表结构打开就明白了
i resovled the problem by keep interfaces and abstract classes original, it's much better than restoring mocked classes after each test execution which will cause JMockit's few functions failure. at...
I sent a email to jdk-dev mailing list to suggest that the maintainers add MethodParameter attribute in JvmtiClassFileReconstituter::write_method_info(), and got response emails that asked if i could reproduce the issue...
OpenJDK assigned bug id: JDK-8240908, RetransformClass does not know about MethodParameters attribute. https://bugs.openjdk.java.net/browse/JDK-8240908
我看了netty的HashedWheelTimer代码并没有修复这个问题。 worker线程执行while循环时,如果有超时任务则直接用worker线程自己去执行,如果执行任务挂住了,那么worker线程也会挂住不动,后面的循环都会一直等着,这样超时机制就会错过正常时间点了。 给netty提的issue: https://github.com/netty/netty/issues/11724
参照netty的做法,sleepTimeMs为0时改为等待1毫秒了。
还要单独创建线程池执行timeout任务,如果复用worker的threadFactory,当池子容量很小,timeout任务很多,任务就会积压,导致timeout任务处理时间严重滞后。
考虑再三还是选了newFixedThreadPool来执行timer task,相比cached线程池,fixed线程池消耗的资源相对较少。只是fixed线程池本身有无限队列的问题,但是如果把等待队列设为有界,我不知道设置多大合适,还有超出队列容量的任务要怎么处理。 即使这样修改,worker thread能够不受task任务影响持续正常运转,但是如果timeout task任务本身代码效率低、执行慢,当排队等待执行的timeout task数量超过newFixedThreadPool容量时,依旧会出超时任务执行时间滞后的问题,这种情况只修改HashedWheelTimer是搞不定的。
event loop和event process的处理线程还是分离好一些,或者像apache httpclient5的FutureRequestExecutionService的构造函数那样,要求用户自己提供一个ExecutorService来执行异步task。