从Tomcat无法正常关闭讲讲Java线程关闭问题

正常情况下,会优先采用catalina.sh stop来停止Tomcat实例,这样可以让服务有机会处理完请求,并做好善后工作。 但如果通过catalina.sh stop命令无法关闭Tomcat实例,则只能kill -9了。

 

为什么在给Tomcat发出stop命令以后,Tomcat实例无法关闭?

 

可能有两种原因:

  • Tomcat的主线程没有结束(也即main函数没有执行结束);
  • Tomcat中启动的webapps有非daemon线程阻[......]

Read more

Posted in 日常文章 | Tagged , | 评论关闭

Junit4:参数化测试

(注意,我要用官方文档开始刷存在感了…)

Junit通过自定义runner——Parameterized来实现参数化测试,参数化测试主要用于需要重复测试不同条件的场景,举个栗子:

public class Fibonacci {
    public static int compute(int n) {
        int result = 0;

        if (n <= 1) {
            result = n;
        }[......]

Read more

Posted in 译文 | Tagged | Leave a comment

Junit4:测试方法执行顺序

(注意,我要用官方文档开始刷存在感了…)

在之前的版本中,Junit在设计上并没有指定测试方法的执行顺序,方法的调用就是根据reflection api的返回顺序。鉴于Java平台并没有规定一个特定的顺序,甚至其返回的顺序有一定的随机性,依赖于JVM的顺序非常的不明智。

 

当然,编写良好的测试用例是不应该依赖于测试方法的执行顺序的。但万一存在这样的情况呢?这个时候“确定顺序”带来的可预测的测试失败总是好过随机的测试失败。

 

从4.11版本开始[......]

Read more

Posted in 日常文章 | Tagged | Leave a comment

Junit4:异常测试

(注意,我要用官方文档开始刷存在感了…)

有些时候,单元测试中需要验证抛出的异常是否是期望得到的,抑或验证抛出异常的message等信息。

这如果是在junit3,一般会通过try catch来处理,在catch中判断异常类型,抑或比较message值。

当然,这一点都不优雅,不但要多谢许多代码,测试用例中充斥的try catch也非常不好看。到了junit4,junit提供了新的方式来支持异常测试。

 

<1> 在@Test中通过expe[......]

Read more

Posted in 日常文章 | Tagged | Leave a comment

Dubbo走读——ExtensionLoader(服务发现)

JAVA提供的服务发现

 

Java1.6开始通过ServiceLoader提供了一种服务发现机制,通过它可以自由选择自己的服务实现。其工作原理是,通过扫描/META-INF/services/下以服务名称(类名称)命名的文件找到对应的服务实现,ServiceLoader返回的是Iterator,如果有多个,则需要由使用方做选择。

 

JDK中有一些实现就用了这种服务发现机制,像SelectorProvider在创建provider的过程中,会通过Ser[......]

Read more

Posted in 日常文章 | Tagged | Leave a comment