Poison

发表于 
1
InputStream InputStream = loader.getResourceAsStream(ipDirInJar + File.separator + dexFileName);

以上代码同事反馈在本地运行时 inputStream 为 null，发现同事使用的 Windows 系统，初步怀疑为编码问题或路径分隔符问题，经过本地 debug，发现寻找 jar 包中的含有路径分隔符的文件时，最终调用了以下方法，在 Windows 系统上返回了 0:

1
2
3
/Library/Java/JavaVirtualMachines/openjdk-8.jdk/Contents/Home/src.zip!/java/util/zip/ZipFile.java:335

private static native long getEntry(long jzfile, byte[] name, boolean addSlash);

经过查询文档，原来 zip 文件里面的路径分隔符必须使用 /，而不能使用平台独立的文件系统路径分隔符，故调整为了 / 解决了该问题。

4.4.17.1 The name of the file, with optional relative path. The path stored MUST NOT contain a drive or device letter, or a leading slash. All slashes MUST be forward slashes ‘/‘ as opposed to backwards slashes ‘' for compatibility with Amiga and UNIX file systems etc. If input came from standard input, there is no file name field.

References

.ZIP File Format Specification
Zip file is created with windows path separator

Poison

发表于

如果我们的 classpath 含有 /tmp/jars/* 这样的通配符，而目录下的不同的 jar 正好含有全限定名称相同的类，这个时候是先加载的哪一个 jar 下面的类呢？这个问题之前一直没搞清楚，之前印象中只是说顺序未定义，但是为什么是未定义的呢，直到一次线上发布，在其中一台机器报类加载相关的错误后，才把这个问题具体的定位了一遍，先从 Java 的系统类加载器说起，我们可以写个简单的程序来验证，比如下面的代码：

1
2
3
4
5
6
7
8
9
package me.tianshuang;

public class Test {

    public static void main(String[] args) {
        System.out.println(System.getProperty("java.class.path"));
    }

}

这段代码非常简单，仅仅打印当前运行时的 classpath，我们直接运行，可以看到以下输出：

1
/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/ext/jaccess.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/jfxswt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/lib/javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/lib/packager.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_291.jdk/Contents/Home/lib/tools.jar:/Users/tianshuang/IdeaProjects/test/target/test-classes:/Users/tianshuang/IdeaProjects/test/target/classes:/Users/tianshuang/.m2/repository/junit/junit/4.12/junit-4.12.jar:/Users/tianshuang/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar
阅读全文 »
Poison

发表于

当执行 FullGC 时，stop-the-world，JVM 其他线程均被暂停执行，基于 Java Agent 的监控方案全部失效，如：JMX Exporter 表现出来的现象就是采集端掉线，Prometheus 中心对 Java Agent 发起请求时因目标 JVM 正在 FullGC 而不能采集数据。那么，此种情况下如果需要监控 GC 情况，则只要保证监控器不使用同一 JVM 实例实现，如 eero 采用的方案为使用 Python 监听 gc.log 再进行上报的方式实现。

Garbagedog: How eero does continuous monitoring of Java garbage collection
garbagedog