OpenTelemetry Java Manual Instrumentation在静态初始化块中阻塞导致类加载死锁？OpenTelemetrySdkBuilder与静态块延迟初始化

好的，没问题。我们开始吧。

OpenTelemetry Java 手动埋点与静态初始化死锁：延迟初始化的艺术

各位同学，大家好。今天我们来探讨一个在使用 OpenTelemetry Java 手动埋点时，经常遇到的一个棘手问题：静态初始化块中的阻塞操作可能导致的类加载死锁。这个问题涉及到类加载机制、静态初始化、线程同步以及 OpenTelemetry SDK 的初始化过程，理解它对于编写健壮的、可观测的应用至关重要。

问题背景：静态初始化与类加载

在深入 OpenTelemetry 之前，我们需要回顾一下 Java 中类加载和静态初始化的基本概念。

类加载过程： 当 Java 虚拟机（JVM）需要使用一个类时，会经历加载、链接（验证、准备、解析）和初始化这几个阶段。其中，初始化阶段负责执行类的静态初始化器（static initializer），也就是包含在 static {} 块中的代码。
静态初始化器： 静态初始化器在类加载过程中只会被执行一次，主要用于初始化静态变量和执行一些需要在类加载时完成的初始化操作。
类加载锁： JVM 在初始化一个类时，会持有该类的类加载锁。这意味着，如果多个线程同时尝试初始化同一个类，只有一个线程能够获得锁并执行初始化器，其他线程会被阻塞，直到初始化完成。

理解这些概念对于我们理解死锁的产生至关重要。

死锁场景：OpenTelemetry SDK 初始化与静态块

现在，让我们考虑一个场景：我们希望在类的静态初始化块中初始化 OpenTelemetry SDK，并使用它来创建一个 Tracer。

import io.opentelemetry.api.OpenTelemetry;
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.sdk.OpenTelemetrySdk;
import io.opentelemetry.sdk.trace.SdkTracerProvider;
import io.opentelemetry.sdk.trace.export.SimpleSpanProcessor;
import io.opentelemetry.exporter.logging.SystemOutSpanExporter;

public class MyClass {

    private static final OpenTelemetry openTelemetry;
    public static final Tracer tracer;

    static {
        // 模拟一些耗时操作
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }

        SdkTracerProvider sdkTracerProvider = SdkTracerProvider.builder()
                .addSpanProcessor(SimpleSpanProcessor.create(SystemOutSpanExporter.create()))
                .build();

        openTelemetry = OpenTelemetrySdk.builder()
                .setTracerProvider(sdkTracerProvider)
                .buildAndRegisterGlobal();

        tracer = openTelemetry.getTracer("MyClassTracer");
    }

    public static void doSomething() {
        tracer.spanBuilder("doSomethingSpan").startSpan().end();
    }

    public static void main(String[] args) {
        doSomething();
    }
}

这段代码看起来很简单，但在某些情况下，它可能会导致死锁。原因如下：

静态初始化依赖： MyClass 的静态初始化器依赖于 OpenTelemetrySdk 的初始化。
OpenTelemetry SDK 初始化阻塞： OpenTelemetrySdk.builder().buildAndRegisterGlobal() 方法可能会执行一些阻塞操作，例如加载配置、连接后端服务等。虽然上面代码中没有体现，但是在复杂的场景下，比如配置了多个Exporter，或者Exporter需要初始化连接第三方服务时，这种情况很容易发生。
多线程并发： 如果另一个线程（例如，由应用服务器管理的线程）也在尝试访问 MyClass，并且此时 MyClass 的静态初始化器尚未完成，那么该线程会被阻塞在类加载锁上。
循环依赖： 如果 OpenTelemetrySdk 的初始化过程又依赖于另一个类的初始化（例如，通过静态变量访问），而这个类又依赖于 MyClass，就形成了循环依赖，导致死锁。

死锁示例：循环依赖

为了更清晰地说明问题，我们创建一个更复杂的示例，模拟循环依赖的情况。

// ClassA.java
public class ClassA {
    public static final String VALUE = ClassB.getValue(); // 依赖 ClassB

    static {
        System.out.println("Initializing ClassA");
    }

    public static String getValue() {
        return "Value from ClassA";
    }
}

// ClassB.java
public class ClassB {
    public static final String VALUE = ClassA.getValue(); // 依赖 ClassA

    static {
        System.out.println("Initializing ClassB");
    }

    public static String getValue() {
        return "Value from ClassB";
    }
}

// Main.java
public class Main {
    public static void main(String[] args) {
        System.out.println(ClassA.VALUE);
    }
}

在这个例子中，ClassA 的静态初始化器依赖于 ClassB 的 getValue() 方法，而 ClassB 的静态初始化器又依赖于 ClassA 的 getValue() 方法。当 Main 类尝试访问 ClassA.VALUE 时，JVM 会尝试初始化 ClassA。在初始化 ClassA 的过程中，它会尝试访问 ClassB.getValue()，这又会导致 JVM 尝试初始化 ClassB。在初始化 ClassB 的过程中，它会尝试访问 ClassA.getValue()，此时 ClassA 仍在初始化中，导致循环等待，最终发生死锁。

OpenTelemetry SDK 初始化阻塞的常见原因

SpanExporter 初始化： 不同的 SpanExporter 可能需要连接到不同的后端服务，例如 Jaeger、Zipkin、Prometheus 等。这些连接操作可能会阻塞。
Resource 检测： OpenTelemetry SDK 会尝试检测运行环境的资源信息，例如主机名、操作系统、云平台等。某些资源检测器可能会执行阻塞操作。
配置加载： OpenTelemetry SDK 支持从环境变量、系统属性、配置文件等加载配置。加载配置的过程可能会阻塞。

解决方案：延迟初始化

解决静态初始化死锁问题的关键在于避免在静态初始化块中执行阻塞操作。一种常见的解决方案是延迟初始化。

1. 延迟初始化 OpenTelemetry SDK

我们可以将 OpenTelemetry SDK 的初始化延迟到真正需要使用 Tracer 的时候。这可以通过使用一个静态的 Holder 类来实现。

import io.opentelemetry.api.OpenTelemetry;
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.sdk.OpenTelemetrySdk;
import io.opentelemetry.sdk.trace.SdkTracerProvider;
import io.opentelemetry.sdk.trace.export.SimpleSpanProcessor;
import io.opentelemetry.exporter.logging.SystemOutSpanExporter;

public class MyClass {

    private static class OpenTelemetryHolder {
        static final OpenTelemetry openTelemetry = createOpenTelemetry();
        static final Tracer tracer = openTelemetry.getTracer("MyClassTracer");

        private static OpenTelemetry createOpenTelemetry() {
            // 模拟一些耗时操作
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }

            SdkTracerProvider sdkTracerProvider = SdkTracerProvider.builder()
                    .addSpanProcessor(SimpleSpanProcessor.create(SystemOutSpanExporter.create()))
                    .build();

            return OpenTelemetrySdk.builder()
                    .setTracerProvider(sdkTracerProvider)
                    .buildAndRegisterGlobal();
        }
    }

    public static Tracer getTracer() {
        return OpenTelemetryHolder.tracer;
    }

    public static void doSomething() {
        getTracer().spanBuilder("doSomethingSpan").startSpan().end();
    }

    public static void main(String[] args) {
        doSomething();
    }
}

在这个版本中，OpenTelemetry 和 Tracer 的初始化被移动到了 OpenTelemetryHolder 类的静态内部类中。只有当 getTracer() 方法被调用时，OpenTelemetryHolder 类才会被加载和初始化，从而延迟了 OpenTelemetry SDK 的初始化。

2. 使用 Supplier 进行懒加载

另一种延迟初始化的方法是使用 Supplier 接口。

import io.opentelemetry.api.OpenTelemetry;
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.sdk.OpenTelemetrySdk;
import io.opentelemetry.sdk.trace.SdkTracerProvider;
import io.opentelemetry.sdk.trace.export.SimpleSpanProcessor;
import io.opentelemetry.exporter.logging.SystemOutSpanExporter;

import java.util.function.Supplier;

public class MyClass {

    private static final Supplier<OpenTelemetry> openTelemetrySupplier = () -> {
        // 模拟一些耗时操作
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }

        SdkTracerProvider sdkTracerProvider = SdkTracerProvider.builder()
                .addSpanProcessor(SimpleSpanProcessor.create(SystemOutSpanExporter.create()))
                .build();

        return OpenTelemetrySdk.builder()
                .setTracerProvider(sdkTracerProvider)
                .buildAndRegisterGlobal();
    };

    private static final Tracer tracer = openTelemetrySupplier.get().getTracer("MyClassTracer");

    public static void doSomething() {
        tracer.spanBuilder("doSomethingSpan").startSpan().end();
    }

    public static void main(String[] args) {
        doSomething();
    }
}

在这个版本中，openTelemetrySupplier 是一个 Supplier 对象，它包含了 OpenTelemetry SDK 的初始化逻辑。只有当 openTelemetrySupplier.get() 方法被调用时，初始化逻辑才会被执行。这种写法和之前的Holder类写法，本质上是一样的。都是利用了JVM的类加载机制，将初始化延迟到真正需要使用的时候。

3. 避免静态初始化器的复杂逻辑

如果静态初始化器中必须包含复杂逻辑，可以考虑将其移到一个单独的方法中，并在需要时调用该方法。这可以减少静态初始化器的执行时间，降低死锁的风险。

总结：最佳实践

为了避免 OpenTelemetry Java 手动埋点导致的静态初始化死锁，请遵循以下最佳实践：

避免在静态初始化块中执行阻塞操作。
使用延迟初始化技术，例如静态内部类或 Supplier 接口。
将复杂的初始化逻辑移到一个单独的方法中。
仔细检查类之间的依赖关系，避免循环依赖。
使用线程池来执行耗时的初始化任务。
考虑使用 OpenTelemetry 的自动埋点功能，它可以减少手动埋点的代码量，降低出错的风险。

表格总结：解决方案对比

解决方案	优点	缺点	适用场景
延迟初始化（静态内部类）	代码简洁，易于理解	需要额外的类来持有 OpenTelemetry SDK 实例	OpenTelemetry SDK 只需要在特定场景下使用，且初始化逻辑不复杂
延迟初始化（Supplier）	代码更灵活，可以动态地创建 OpenTelemetry SDK 实例	代码稍微复杂一些	OpenTelemetry SDK 的初始化逻辑比较复杂，需要动态地配置
避免复杂逻辑	减少静态初始化器的执行时间，降低死锁风险	需要重新组织代码结构	静态初始化器中包含复杂逻辑，无法避免
线程池	将耗时的初始化任务放在后台线程中执行，避免阻塞主线程	需要管理线程池的生命周期，增加代码复杂性	初始化任务非常耗时，且不影响应用启动的关键流程
自动埋点	减少手动埋点的代码量，降低出错的风险	需要额外的配置，可能无法满足所有定制化需求	应用的埋点需求比较通用，可以使用 OpenTelemetry 提供的自动埋点功能

实际案例分析

假设我们有一个 Spring Boot 应用，需要在应用启动时初始化 OpenTelemetry SDK，并将其注册为全局 TracerProvider。

@SpringBootApplication
public class MyApplication {

    private static final Logger logger = LoggerFactory.getLogger(MyApplication.class);

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
        logger.info("Application started");
    }

    @Bean
    public OpenTelemetry openTelemetry() {
        // 模拟一些耗时操作
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }

        SdkTracerProvider sdkTracerProvider = SdkTracerProvider.builder()
                .addSpanProcessor(SimpleSpanProcessor.create(SystemOutSpanExporter.create()))
                .build();

        return OpenTelemetrySdk.builder()
                .setTracerProvider(sdkTracerProvider)
                .buildAndRegisterGlobal();
    }
}

如果 openTelemetry() 方法中的初始化逻辑比较耗时，可能会导致 Spring Boot 应用启动缓慢，甚至出现死锁。为了解决这个问题，我们可以使用 Spring 的异步初始化机制。

@SpringBootApplication
@EnableAsync
public class MyApplication {

    private static final Logger logger = LoggerFactory.getLogger(MyApplication.class);

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
        logger.info("Application started");
    }

    @Bean
    @Async
    public CompletableFuture<OpenTelemetry> openTelemetry() {
        return CompletableFuture.supplyAsync(() -> {
            // 模拟一些耗时操作
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }

            SdkTracerProvider sdkTracerProvider = SdkTracerProvider.builder()
                    .addSpanProcessor(SimpleSpanProcessor.create(SystemOutSpanExporter.create()))
                    .build();

            return OpenTelemetrySdk.builder()
                    .setTracerProvider(sdkTracerProvider)
                    .buildAndRegisterGlobal();
        });
    }
}

在这个版本中，我们使用了 @Async 注解将 openTelemetry() 方法标记为异步方法。 Spring 会使用一个线程池来执行该方法，从而避免阻塞主线程。同时，我们使用了 CompletableFuture 来处理异步操作的结果。请注意，为了使 @Async 注解生效，需要在应用中启用异步支持，即添加 @EnableAsync 注解。

总结：小心静态初始化，巧妙延迟加载，异步并发助力

通过今天的学习，我们了解了 OpenTelemetry Java 手动埋点中静态初始化死锁的产生原因和解决方案。记住，在编写代码时，要小心静态初始化，尽量避免在静态初始化块中执行阻塞操作。如果必须执行阻塞操作，可以使用延迟初始化、线程池等技术来避免死锁。此外，还要仔细检查类之间的依赖关系，避免循环依赖。总之，理解类加载机制和线程同步原理，并灵活运用各种技术手段，才能编写出健壮的、可观测的应用。

发表回复 取消回复

发表回复取消回复