Java 14中的 JEP 358: Helpful NullPointerExceptions是如何实现的

  Language / Java 13 分钟读完 (大约1918个字)

Java 14在2020年3月17号正式发布，不久AdoptOpenJDK也跟进发布了新版。

JEP 358: Helpful NullPointerExceptions

其中对使用者比较有用的功能是 JEP 358: Helpful NullPointerExceptions，即在NullPointerException的message中指明为什么产生了这个NPE。

示例代码如下（需要Java14，并配置参数-XX:+ShowCodeDetailsInExceptionMessages）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
public class Main {
    static class Class1 {
        Object object;
    }
    static class Class2 {
        Class1 class1;
        public Class1 getClass1() {
            return class1;
        }
    }
    static Class2 class2;
    private static Object get(int i) {
        return null;
    }
    // 打印NPE的message
    private static void printNPE(Runnable runnable) {
        try {
            runnable.run();
        } catch (NullPointerException e) {
            System.err.println(e.getMessage());
        }
    }
    public static void main(String[] args) {
        Class2 class21 = null;
        printNPE(() -> {
            // 1. getstatic为null
            // Cannot invoke "Main$Class2.getClass1()" because "Main.class2" is null
            System.out.println(class2.getClass1().object.toString());
        });
        Class2 class22 = new Class2();
        printNPE(() -> {
            // 2. 调用函数结果为null
            // Cannot read field "object" because the return value of "Main$Class2.getClass1()" is null
            System.out.println(class22.getClass1().object.toString());
        });
        class22.class1 = new Class1();
        printNPE(() -> {
            // 3. 函数调用后，getfield为null
            // Cannot invoke "Object.toString()" because "Main$Class2.getClass1().object" is null
            System.out.println(class22.getClass1().object.toString());
        });
        printNPE(() -> {
            // 4. 链式getfield
            // Cannot invoke "Object.toString()" because "class22.class1.object" is null
            System.out.println(class22.class1.object.toString());
        });
        Integer[] ary1 = null;
        printNPE(() -> {
            // 5. 对null执行aaload
            // Cannot load from object array because "ary1" is null
            System.out.println(ary1[0].intValue());
        });
        Integer[] ary2 = new Integer[1];
        printNPE(() -> {
            // 6. iconst_0+aaload后为null
            // Cannot invoke "java.lang.Integer.intValue()" because "ary2[0]" is null
            System.out.println(ary2[0].intValue());
        });
        printNPE(() -> {
            int i = 0;
            // 7. iconst_0+iload_1后为null
            // Cannot invoke "java.lang.Integer.intValue()" because "ary2[i]" is null
            System.out.println(ary2[i].intValue());
        });
        printNPE(() -> {
            int i = 0;
            // 8. iconst_0+iadd后为null
            // Cannot invoke "java.lang.Integer.intValue()" because "ary2[...]" is null
            System.out.println(ary2[i + 0].intValue());
        });
        printNPE(() -> {
            // 9. invokevirtual结果为null
            // Cannot invoke "Object.toString()" because the return value of "Main.get(int)" is null
            System.out.println(Main.get(1).toString());
        });
    }
}

令我比较意外的是情况4和情况7，Java能够追溯链式回调，而且连变量名都带上了！

JEP 358实现细节

那我们就看下这么神奇的特性是如何实现的吧。

首先，这个功能需要添加参数-XX:+ShowCodeDetailsInExceptionMessages才能开启，那我们只要在JDK的代码中搜索这个字符串就行。于是找到给NPE填充Message的代码：

 
  阅读更多

jdk 8u91一个lambda类型推断的bug

  Language / Java 3 分钟读完 (大约491个字)

公司内部发布maven包是在公司构建服务器上编译的。最近一次上线，发现同样的代码，在本地的jdk8上能编译通过，但是在构建服务器上，就编译报错。

简化后的代码如下：

JavaBugTest.java
1
2
3
4
5
6
7
8
9
10
11
12
13
import java.util.Optional;

public class JavaBugTest {

    public static <T, E extends Throwable> T execute(RetryCallback<T, E> retryCallback) throws E {
        return retryCallback.doWithRetry(new Object());
    }

    public static void main(String[] args) {
        Optional.ofNullable(execute((param) -> new Object()))
                .ifPresent(s -> System.out.println(s));
    }
}
RetryCallback.java
1
2
3
public interface RetryCallback<T, E extends Throwable> {
    T doWithRetry(Object var1) throws E;
}

用maven编译报错如下：

1
JavaBugTest.java:[10,36] unreported exception E; must be caught or declared to be thrown

最后发现，是构建服务器jdk版本太老导致的。

二分法尝试了几个版本，发现8u91不行，但是8u92就能编译通过了。

于是开始调试javac代码，发现两个版本的AST不一样：

 
  阅读更多

HashMap的初始容量设置

  Language / Java 6 分钟读完 (大约955个字)

先说结论

知道大小的情况下，new HashMap的时候这么写：

1
HashMap<Integer, String> map = Maps.newHashMapWithExpectedSize(expectedSize);

正文

Java中的HashMap大家都很熟悉，其底层使用了Node数组来存储Map中的数据。但是如果存储的数据太多，空间不够，就需要扩容这个数组来存储新的数据了。

扩容的实现可以看下java.util.HashMap#resize函数，基本上就是将数组中的内容逐个复制到新数组中。

扩容操作的时间复杂度是O(n)，空间复杂度是O(n)，还需要计算对象的hash。在平常编码中，如果我们提前知道map的大小，就应该指定初始容量，避免发生扩容。

《阿里巴巴开发手册》中也有这么一条建议：

于是，很多开发者（包括刚开始的我），就这么写：

  阅读更多

如何以string方式查看heapdump中的byte数组

  Language / Java 2 分钟读完 (大约305个字)

昨天，线上OOM，dump下来hprof文件，里面有两个大数组：

从表象上来看，和thrift导致的oom是一样的：

但是问题是，这种情况是怎么出现的呢？

找了好几种办法，没有头绪。

最后发现，把这个byte数组转成string就看到了thrift服务端的错误信息。

当时为了快速解决问题，是直接将前60个byte手抄到java代码中，然后转成string输出。

但是，不能一直都这么干，所以就看了下如何方便的将heapdump中的byte[]输出为string。

查了半天，发现OQL没有这样的功能，但是VisualVM倒是可以间接的做这事：

  阅读更多

不正确使用Thrift Client导致的OOM问题排查

  Language / Java 4 分钟读完 (大约607个字)

最近线上有一个多线程的任务，会调用几个Thrift服务。 上线后观察到这个脚本在执行一段时间后，会有好几次Full GC，然后就会报OOM错误。

那就先下载heap dump（推荐压缩后，使用rz下载到本地），使用VisualVM分析。首先切换到Objects页面，看下是否有大对象：

heapdump-Objects

可以看到，有两个byte数组占用了大量内存，也可以看到这个对象是在Java栈上的，接下来就是要找谁在使用这个变量。

右击该对象，点击Select in Threads：

可以看到是名为rebuilder-9的线程，再查看这个线程的调用栈：

再结合readStringBody的代码：

 
  阅读更多

lambda表达式导致arthas无法redefine的问题

  Language / Java 7 分钟读完 (大约1062个字)

作为一个从PHP转Java的人，发现alibaba的arthas很好用。通过arthas的redefine命令，可以像PHP一样，不用重新发布，就可以改变程序行为（前提是不改变类结构，不改变方法签名）。

但是用多了，发现很多时候，我们就改了几行代码，甚至有的时候就添加了一行日志，就无法redefine了。提示

redefine error! java.lang.UnsupportedOperationException: class redefinition failed: attempted to add a method

它提示我们新增加方法，那我们就看看是不是新增加了方法。通过javap来查看定义的方法：

老的类：

新的类：

对比之后发现，新的类，即本地编译的类，其中的lambda对应的方法名都是lambda$getAllCity$0这样的。

 
  阅读更多

从fastjson漏洞谈防御式编程

  Language / Java 5 分钟读完 (大约757个字)

最近，fastjson又爆出一个漏洞，在解析特殊字符的时候，直接OOM：

首先分析一下整体流程：

在scanString时，会直接读取两个字符：

而在next方法中，每次读取都会将bp的值加一（即使没有从输入中读取字符）：

1
2
3
4
5
6
public final char next() {
    int index = ++bp;
    return ch = (index >= this.len ? //
            EOI //
            : text.charAt(index));
}

在处理完x之后，继续解析剩下的字符。由于没有更多字符了，所以读到的总是EOI，然后进入如下分支：

1
2
3
4
5
6
7
if (ch == EOI) {
    if (!isEOF()) {
        putChar((char) EOI);
        continue;
    }
    throw new JSONException("unclosed string : " + ch);
}

本来到这一步，isEOF应该是true了，但是isEOF是这样的：

  阅读更多

AsyncHttpClient对Cookie的控制太不灵活了

  Language / Java 4 分钟读完 (大约558个字)

业务上遇到一个坑，java服务代理了一个接口到upstream，原样转发请求数据和头部。但是代理之后的结果总是莫名其妙的多了一个Cookie，比如是Set-Cookie: ticket=t1。

业务上用一个静态的AsyncHttpClient来做代理，也没有做特殊处理，基本上就是如下的代码逻辑：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
import org.asynchttpclient.*;

import java.io.IOException;
import java.util.concurrent.ExecutionException;

class Main {
    private static AsyncHttpClient httpClient;

    static {
        DefaultAsyncHttpClientConfig.Builder builder = new DefaultAsyncHttpClientConfig.Builder();

        httpClient = new DefaultAsyncHttpClient(builder.build());
    }

    public static void main(String[] args) throws ExecutionException, InterruptedException, IOException {
        BoundRequestBuilder builder = httpClient.prepareGet(
                "https://httpbin.org/cookies/set/ticket/val1"
        );
        builder.resetCookies();
        builder.execute().get();

        BoundRequestBuilder builder2 = httpClient.prepareGet(
                "https://httpbin.org/cookies"
        );
        builder2.resetCookies();
        Response res2 = builder2.execute().get();
        System.out.println(res2.getResponseBody());
    }
}

当时为了防止Cookie问题，特意加上了resetCookies。

首先是查看ticket Cookie的来源，发现upstream在客户端请求带上ticket Cookie的时候，会返回Set-Cookie: ticket=<val> 这个应该就是多余Cookie的来源了。

但是，即使客户端不带Cookie，java服务这边也会返回Set-Cookie字段。这个问题，排查之后发现问题在于resetCookies只能reset本次请求的Cookie，而客户端的Cookie，则不能清除。

即，某次请求，upstream返回了Set-Cookie: ticket=val，那么，以后的代理请求中，都会带上这个Cookie，那么最终用户也会拿到Set-Cookie字段……

从上述代码的运行结果也可以看出：

1
2
3
4
5
{
  "cookies": {
    "ticket": "val1"
  }
}

即，async-http-client没有一个request级别的Cookie控制，只能全局控制Cookie存储。这个问题也有人反馈给了async-http-client。

  阅读更多

PHP Generator相关的设计失误

  Language / PHP 5 分钟读完 (大约750个字)

PHP的Generator，也就是 yield/yield from 语法，使得函数调用可以“暂停”执行，并保留上下文，并在后续可以恢复执行。

但是，在PHP后续的设计中，很多地方都没有考虑到Generator：

Return Type Declarations（返回类型声明）

RFC见https://wiki.php.net/rfc/return_types。简而言之，可以给函数声明返回类型。先来看一段代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<?php
declare(strict_types=1);

function inner(): Iterator
{
    yield __FUNCTION__;
    return 1;
}

function gen(): Generator
{
    yield __FUNCTION__;
    return yield from inner();
}

try {
    $gen = gen();
    foreach ($gen as $yielded) {
        echo "yield: ".$yielded . PHP_EOL;
    }
    echo "return: " . $gen->getReturn() . PHP_EOL;
} catch (Exception $e) {
    echo PHP_EOL;
    echo $e->getTraceAsString();
    echo PHP_EOL;
}

gen/inner函数是一个generator，yield的的类型是string，return的类型是int。但为了让PHP不报错，gen/inner函数的返回类型只能声明为Iterator或Generator——这完全破坏了返回类型声明的初衷：

对于普通函数，返回类型声明用来表示返回类型；对于generator，返回类型声明用来表示这是一个迭代器/Generator。（听着很不一致的样子）

好，没关系，无伤大雅。没法通过返回类型声明来推倒类型而已，我们通过PhpDoc来总可以了吧？

通过PhpDoc来标记返回类型

但是这个怎么写呢？对于刚刚的inner函数（yield的的类型是string，return的类型是int），最自然的写法是这样：

 
  阅读更多

Java中的SPI机制

  Language / Java 4 分钟读完 (大约553个字)

SPI 全称为 (Service Provider Interface) ，是Java 1.6之后内置的一种服务提供发现机制。SPI可以通过配置来替换服务（或者说interface）的实现；比如java.sql.Driver接口，可以很轻松的从MySQL切换到MongoDB实现。

问题的核心在于，如何根据interface查找对应的实现。

SPI的实现

Java 1.6中，开发者只需要在META-INF/services下添加文件，即可切换、修改对应interface的实现。文件名为实现的接口，文件内容为N个实现的类名，按行分隔。比如：

1
2
3
$ cat src/main/resources/META-INF/services/com.robberphex.Plugin 
com.robberphex.impl.PluginImpl1
com.robberphex.impl.PluginImpl2

使用起来，主要就是ServiceLoader类：

1
2
3
4
ServiceLoader<Plugin> loader = ServiceLoader.load(Plugin.class);
for (Plugin plugin : loader) {
    System.out.println(plugin.getClass().getCanonicalName());
}

要注意的是，ServiceLoader#load方法是CallerSensitive的，即load的时候用的是调用者的类加载器。

Java 9

Java 9之后，由于模块化的引入，所以SPI机制也做了扩展：除了原有的通过META-INF/services来注册服务外，还可以通过module中的provides…with语句来注册服务：

 
  阅读更多
Robert Lu

关注我的公众号

最新文章

标签

Arthas1
Desktop5
Docker1
Firefox1
Go3
Golang3
HTTP1
HiDPI1
Input2
JVM1
Java16
Kubernetes1
LeetCode12
Linux8
PEP1
PHP12
Python4
Redis1
Scala1
Spring Cloud2
TLS1
VSCode1
django1
gRPC1
ssh1
uWSGI1
云原生3
垃圾回收1
源码分析1
翻译8
面试1

链接

广告

×