Interface ProfilerBackend

All Known Implementing Classes:
BinaryBackend, LibraryBackend

@Private interface ProfilerBackend
Abstraction over async-profiler execution. Implementations handle either the in-process Java API (LibraryBackend, when the maven dependency is on the classpath) or the external binary (BinaryBackend, when ASYNC_PROFILER_HOME is set).

This file deliberately contains no import of one.profiler.AsyncProfiler. That import is isolated in LibraryBackend so that binary-only deployments never trigger a NoClassDefFoundError when this class is loaded.

  • Field Details

    • LOG

      static final org.slf4j.Logger LOG
  • Method Details

    • executeStart

      Executes a profiling start command and returns the profiler's response.
      Throws:
      IOException
    • executeStop

      Executes a profiling stop/dump command.
      Throws:
      IOException
    • destroy

      default void destroy()
      Cleans up any resources (e.g. kills a running process). Called on servlet destroy.
    • detect

      static ProfilerBackend detect(String asyncProfilerHome)
      Detects which backend is available. Prefers LibraryBackend over BinaryBackend. Returns null if neither is available.

      Detection runs once at class-load time (via DETECTED_BACKEND in ProfileServlet). A library that becomes loadable after the JVM starts requires a restart to be detected. A library that resolves at class-load but whose native binary is incompatible with the OS/kernel will not surface the error here — it will throw an Error or RuntimeException on the first execute() call at request time.

      When both the library and a binary home are available, LibraryBackend is preferred and ASYNC_PROFILER_HOME is ignored.

      LibraryBackend is instantiated reflectively so that its class — and therefore one.profiler.AsyncProfiler — is never loaded on systems where the JAR is absent.