Java 9 - JEP 259: API-интерфейс стека

JEP 259 предоставляет эффективный стандартный API для стекирования, который позволяет легко фильтровать и ленивый доступ к информации в стеках. Перед API Stack-Walking обычными способами доступа к фреймам стека были:

Throwable::getStackTrace и Thread::getStackTrace возвращать массив из StackTraceElement объектов, которые содержат имя класса и имя метода каждого Элемент stack-trace.

SecurityManager::getClassContext - защищенный метод, который позволяет подклассу SecurityManager обращаться к контексту класса.

JDK-internal sun.reflect.Reflection::getCallerClass метод, который вы должны 't use anyway

Использование этих API обычно неэффективно:

Эти API требуют, чтобы виртуальная машина охотно захватывала моментальный снимок всего стека, и они возвращаются информация, представляющая весь стек. Невозможно избежать затрат на изучение всех кадров, если вызывающий объект интересуется только несколькими кадрами в стеке.

Чтобы найти класс непосредственного вызывающего, сначала получите a StackWalker:

StackWalker walker = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);

Затем либо вызовите getCallerClass():

Class<?> callerClass = walker.getCallerClass();

, либо walk StackFrame s и получите первое предыдущее StackFrame :

walker.walk(frames -> frames.map(StackWalker.StackFrame::getDeclaringClass).skip(1).findFirst());

Мне нравится new Exception("some message to find the exception easier").printStackTrace() больше.

private void parseExceptionContents(
      final Exception exception,
      final OutputStream out)
   {
      final StackTraceElement[] stackTrace = exception.getStackTrace();
      int index = 0;
      for (StackTraceElement element : stackTrace)
      {
         final String exceptionMsg =
              "Exception thrown from " + element.getMethodName()
            + " in class " + element.getClassName() + " [on line number "
            + element.getLineNumber() + " of file " + element.getFileName() + "]";
         try
         {
            out.write((headerLine + newLine).getBytes());
            out.write((headerTitlePortion + index++ + newLine).getBytes() );
            out.write((headerLine + newLine).getBytes());
            out.write((exceptionMsg + newLine + newLine).getBytes());
            out.write(
               ("Exception.toString: " + element.toString() + newLine).getBytes());
         }
         catch (IOException ioEx)
         {
            System.err.println(
                 "IOException encountered while trying to write "
               + "StackTraceElement data to provided OutputStream.\n"
               + ioEx.getMessage() );
         }
      }
   }

Я сделал это раньше. Вы можете просто создать новое исключение и захватить трассировку стека, не бросая его, а затем проверить трассировку стека. Как сказал другой ответ, это очень дорого - не делайте этого в трудном цикле.

Я сделал это раньше для утилиты регистрации в приложении, где производительность не имеет большого значения ( Производительность редко имеет значение вообще, на самом деле - пока вы показываете результат на такое действие, например, быстро нажимаете кнопку).

До того, как вы смогли получить трассировку стека, исключения имели только .printStackTrace (), поэтому мне пришлось перенаправить System.out на поток моего собственного творения, затем (новый Exception ()). printStackTrace ( ); Перенаправить System.out назад и проанализировать поток. Интересный материал.

Альтернативное решение можно найти в комментарии к этому запросу для улучшения . Он использует метод getClassContext() пользовательского SecurityManager и, кажется, быстрее, чем метод трассировки стека.

Следующая программа проверяет скорость различных предложенных методов (наиболее интересный бит находится в внутренний класс SecurityManagerMethod):

/**
 * Test the speed of various methods for getting the caller class name
 */
public class TestGetCallerClassName {

  /**
   * Abstract class for testing different methods of getting the caller class name
   */
  private static abstract class GetCallerClassNameMethod {
      public abstract String getCallerClassName(int callStackDepth);
      public abstract String getMethodName();
  }

  /**
   * Uses the internal Reflection class
   */
  private static class ReflectionMethod extends GetCallerClassNameMethod {
      public String getCallerClassName(int callStackDepth) {
          return sun.reflect.Reflection.getCallerClass(callStackDepth).getName();
      }

      public String getMethodName() {
          return "Reflection";
      }
  }

  /**
   * Get a stack trace from the current thread
   */
  private static class ThreadStackTraceMethod extends GetCallerClassNameMethod {
      public String  getCallerClassName(int callStackDepth) {
          return Thread.currentThread().getStackTrace()[callStackDepth].getClassName();
      }

      public String getMethodName() {
          return "Current Thread StackTrace";
      }
  }

  /**
   * Get a stack trace from a new Throwable
   */
  private static class ThrowableStackTraceMethod extends GetCallerClassNameMethod {

      public String getCallerClassName(int callStackDepth) {
          return new Throwable().getStackTrace()[callStackDepth].getClassName();
      }

      public String getMethodName() {
          return "Throwable StackTrace";
      }
  }

  /**
   * Use the SecurityManager.getClassContext()
   */
  private static class SecurityManagerMethod extends GetCallerClassNameMethod {
      public String  getCallerClassName(int callStackDepth) {
          return mySecurityManager.getCallerClassName(callStackDepth);
      }

      public String getMethodName() {
          return "SecurityManager";
      }

      /** 
       * A custom security manager that exposes the getClassContext() information
       */
      static class MySecurityManager extends SecurityManager {
          public String getCallerClassName(int callStackDepth) {
              return getClassContext()[callStackDepth].getName();
          }
      }

      private final static MySecurityManager mySecurityManager =
          new MySecurityManager();
  }

  /**
   * Test all four methods
   */
  public static void main(String[] args) {
      testMethod(new ReflectionMethod());
      testMethod(new ThreadStackTraceMethod());
      testMethod(new ThrowableStackTraceMethod());
      testMethod(new SecurityManagerMethod());
  }

  private static void testMethod(GetCallerClassNameMethod method) {
      long startTime = System.nanoTime();
      String className = null;
      for (int i = 0; i < 1000000; i++) {
          className = method.getCallerClassName(2);
      }
      printElapsedTime(method.getMethodName(), startTime);
  }

  private static void printElapsedTime(String title, long startTime) {
      System.out.println(title + ": " + ((double)(System.nanoTime() - startTime))/1000000 + " ms.");
  }
}

Пример вывода с моего 2,4 ГГц Intel Core 2 Duo MacBook с поддержкой Java 1.6.0_17:

Reflection: 10.195 ms.
Current Thread StackTrace: 5886.964 ms.
Throwable StackTrace: 4700.073 ms.
SecurityManager: 1046.804 ms.

Внутреннее отражение метод много быстрее других. Получение трассировки стека из вновь созданного Throwable происходит быстрее, чем получение его от текущего Thread. И среди невнутренних способов поиска класса вызывающего абонента пользовательский SecurityManager кажется самым быстрым.

Update

Как говорит Льюми в этот комментарий метод sun.reflect.Reflection.getCallerClass() по умолчанию отключен в обновлении 40 Java 7 и полностью удален в Java 8. Подробнее об этом читайте в этой проблеме в базе данных ошибок Java .

Обновление 2

Как заметил zammbi, Oracle был вынужден вернуться из изменения , который удалил sun.reflect.Reflection.getCallerClass().

Обновление 3

Через 3 года: обновление времени с использованием текущей JVM.

> java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
> java TestGetCallerClassName
Reflection: 0.194s.
Current Thread StackTrace: 3.887s.
Throwable StackTrace: 3.173s.
SecurityManager: 0.565s.

Похоже, вы пытаетесь избежать передачи ссылки на this в метод. Передача this намного лучше, чем поиск вызывающего абонента по текущей трассировке стека. Рефакторинг для более OO-дизайна еще лучше. Вам не нужно знать вызывающего абонента. При необходимости передайте объект обратного вызова.

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.PrintWriter;

class DBConnection {
    String createdBy = null;

    DBConnection(Throwable whoCreatedMe) {
        ByteArrayOutputStream os = new ByteArrayOutputStream();
        PrintWriter pw = new PrintWriter(os);
        whoCreatedMe.printStackTrace(pw);
        try {
            createdBy = os.toString();
            pw.close();
            os.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

public class ThrowableTest {

    public static void main(String[] args) {

        Throwable createdBy = new Throwable(
                "Connection created from DBConnectionManager");
        DBConnection conn = new DBConnection(createdBy);
        System.out.println(conn.createdBy);
    }
}

ИЛИ

public static interface ICallback<T> { T doOperation(); }


public class TestCallerOfMethod {

    public static <T> T callTwo(final ICallback<T> c){
        // Pass the object created at callee to the caller
        // From the passed object we can get; what is the callee name like below.
        System.out.println(c.getClass().getEnclosingMethod().getName());
        return c.doOperation();
    }

    public static boolean callOne(){
        ICallback callBackInstance = new ICallback(Boolean){
            @Override
            public Boolean doOperation() 
            {
                return true;
            }
        };
        return callTwo(callBackInstance);
    }

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

Этот метод делает то же самое, но немного более просто и, возможно, немного более результативно, и в случае, если вы используете отражение, он автоматически пропускает эти кадры. Единственная проблема заключается в том, что он может отсутствовать в JVM, отличном от Sun, хотя он включен в классы времени выполнения JRockit 1.4 -> 1.6. (Точка не является классом public ).

sun.reflect.Reflection

    /** Returns the class of the method <code>realFramesToSkip</code>
        frames up the stack (zero-based), ignoring frames associated
        with java.lang.reflect.Method.invoke() and its implementation.
        The first frame is that associated with this method, so
        <code>getCallerClass(0)</code> returns the Class object for
        sun.reflect.Reflection. Frames associated with
        java.lang.reflect.Method.invoke() and its implementation are
        completely ignored and do not count toward the number of "real"
        frames skipped. */
    public static native Class getCallerClass(int realFramesToSkip);

Насколько известно значение realFramesToSkip, версии Sun 1.5 и 1.6 VM java.lang.System, существует метод защиты пакетов, называемый getCallerClass (), который вызывает sun.reflect.Reflection.getCallerClass(3), но в моем классе вспомогательной утилиты, который я использовал 4, поскольку есть добавленный фрейм вызова вспомогательного класса.