Я работаю над аспектом аспекта, который должен знать, откуда он вызывается. В настоящий момент я используюБыстрый доступ к информации о вызывающем абоненте
new Throwable().getStackTrace();
для доступа к этой информации, но каждый аспект занимает несколько сотен микросекунд.
Я посмотрел на SecurityManager, но, похоже, мне удалось получить имя класса.
Есть ли другие альтернативы, которые я пропустил?
Update
результаты JMH Benchmark, упомянутые в моем комментарии на @ apangin отвечают:
Benchmark Mode Cnt Score Error Units
MyBenchmark.javalangaccess13i avgt 100 2025.865 ± 8.133 ns/op
MyBenchmark.javalangaccess2i avgt 100 2648.598 ± 24.369 ns/op
MyBenchmark.throwable1 avgt 100 12706.978 ± 84.651 ns/op
Benchmark код:
@Benchmark
public StackTraceElement[] throwable1() {
return new Throwable().getStackTrace();
}
@SuppressWarnings("restriction")
@Benchmark
public static StackTraceElement javalangaccess2i() {
Exception e = new Exception();
return sun.misc.SharedSecrets.getJavaLangAccess().getStackTraceElement(e, 2);
}
@SuppressWarnings("restriction")
@Benchmark
public static StackTraceElement javalangaccess13i() {
Exception e = new Exception();
return sun.misc.SharedSecrets.getJavaLangAccess().getStackTraceElement(e, 13);
}
тесты работают под управлением Windows 10, JDK 1.8. 0_112 на Dell XPS13 9343 (i5-5200U при частоте 2,2 ГГц)
Очевидный вопрос: зачем вам это нужно. Получение трассировки стека занимает довольно много времени по разным причинам, поэтому лучше всего найти альтернативное решение вашей исходной проблемы, которое не связано с чтением по трассе стека. – biziclop
Получение информации о вызывающем абоненте происходит медленно. Например, каждая система ведения журнала имеет эту проблему. И все они советуют вам не включать такую информацию, если вам нужна производительность. – zapl
Как говорится в других комментариях: то, что вы пропустите, состоит в том, что у вас есть противоречащие требованиям, которые вам нужно как-то разрешить; так как вы не найдете разумного и надежного способа выполнить их все. – GhostCat