codeReview中的奇妙代码

229次阅读
一条评论
codeReview中的奇妙代码

1.

codeReview中的奇妙代码
某位同事的代码,有点小问题

这段代码的问题在于判断Status是个Integer类型的,在这里却直接用==来和int比较,其实这里还好 因为Integer在和int对比的时候会自动拆箱 拆成int再比较 比较的虽然是地址 但是也同是常量池中的“2”的地址,只是会有性能上的损耗。但是难保以后会不会出现Integer==Integer这样的判断,如果其中Integer如果不在【-128,127】中,那么就不会比较缓存了,就一定会出问题~更不用说new出来的Integer了(放堆中)。

2.

codeReview中的奇妙代码
我的代码

这段代码的问题在于我使用了异常的printStackTrace来打印堆栈,而在日志框架中只是简单的打印了信息 没有打印异常

关于使用日志框架而非printStackTrace 的讨论 ,stackOverFLow中说的很好了,地址:

https://stackoverflow.com/questions/10477607/avoid-printstacktrace-use-a-logger-call-instead

贴一段里面的内容


If you call printStackTrace() on an exception the trace is written to System.err and it's hard to route it elsewhere (or filter it). Instead of doing this you are adviced to use a logging framework (or a wrapper around multiple logging frameworks, like Apache Commons Logging) and log the exception using that framework (e.g. logger.error("some exception message", e)).

  • write the log statement to different locations at once, e.g. the console and a file
  • filter the log statements by severity (error, warning, info, debug etc.) and origin (normally package or class based)
  • have some influence on the log format without having to change the code
  • etc.

3.

codeReview中的奇妙代码
我们项目的nacos配置一角

理应会打印在控制台但是却诡异的没能打印出来的日志:

The Hystrix timeout of XXXXms for the command serviceA is set lower than the combination of the Ribbon read and connect timeout, XXXXXms.

如图我们可以看到hystrix的熔断时间是50000毫秒 , 而ribbon的请求连接的超时时间是60000毫秒 先不说这个时间是否合理,先说这个问题:hystrix的熔断时间可以比ribbon的连接超时时间短吗?

通过看tystrix的代码可以得到这个计算方式:

ribbonTimeout = (ribbon.ConnectTimeout + ribbon.ReadTimeout) * (ribbon.MaxAutoRetries + 1) * (ribbon.MaxAutoRetriesNextServer + 1);

根据这个公式我们可以推算ribbon的时机超时时间是12000*3*2=72000毫秒=1分钟12秒,而Hystrix的熔断时间应当大雨ribbon超时时间 所以熔断时间至少是1分12秒。。。。。。你就说离不离谱就完了

评论(一条评论)
2020-12-10 03:22:51 回复

There is certainly a great deal to find out about this subject. I like all the points you made. Janette Aksel Fortunato