Определите, выполняется ли вызов метода в нескольких потоках

Question

Так недавно меня спросили об этом интервью:

Предположим, вам дали стороннюю библиотеку черного ящика java, вы вызываете метод из этой библиотеки. Как вы можете определить, выполняется ли этот вызов метода в нескольких потоках?

Я упоминал, что могу:

• Получить дамп потока и узнать
• Запустите профилировщик и проверьте оттуда
• проверьте, используя Thread.currentThread () .getName ()

* 1022. * Но, похоже, их ответы не удовлетворили. Как правильно ответить на это?

Answer 1

Существует функция Thread.activeCount(), которая дает вам количество текущих активных потоков.

Вы можете сохранить возвращаемое значение перед вызовом стороннего метода и сравнить его с возвращенным значение во время его работы.

Вы должны убедиться, что не создаете / не завершаете потоки вне метода во время его работы, иначе это повлияет на результат.

Answer 2

StackWalker и Thread.getStacktrace можно использовать для перечисления всех текущих активных методов, примерно так должно работать, более или менее:

Set<Thread> threads = Thread.getAllStackTraces().keySet();
for (Thread thread : threads) {
    for (StackTraceElement stackTraceElement : thread.getStackTrace()) {
        stackTraceElement.getClassName()
        stackTraceElement.getMethodName();
    }
}

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

Answer 3

Что ж, очевидный ответ - посмотреть на исходный код. Я знаю, что он сказал «черный ящик», но там нет такого, где задействован код. Это просто, если у меня есть и library.jar, и library-sources.jar, но даже если все, что у меня есть, это library.jar, просто используйте для него декомпилятор. Это перемещает проблему от «свидетельства многопоточности» к «подтверждению многопоточности».

Второй лучший способ - использовать RTFM. Задокументировано ли использование потоков и / или потокобезопасность? Ну вот и go. Но, как мы все знаем, документации всегда не хватает, поэтому на это у меня мало надежды. Тем не менее, иногда вам везет.

Тогда ... Я бы сделал go там, где вы были с профилями и дампами потоков и т.д. c.

Тем не менее, это довольно плохо вопрос. Как вопрос рабочий , кого волнует, является ли библиотека многопоточной, если она выполняется правильно и работает быстро. Это не ваш код, поэтому, если он не работает (точность или производительность), вам все равно, почему - go скажите, кому он принадлежит, исправить это.

В качестве вопроса собеседования вы оцениваете навыки решения проблем. Подходит ли к этому соискатель по-разному. Чем больше способов атаковать проблему, тем старше человек, с которым вы, вероятно, имеете дело - проверка исходного кода, декомпиляция, профили, дампы потоков, сообщения журнала, документация, et c, et c. Самые высокопоставленные люди скажут вам, «кого это волнует, если это черный ящик, это не моя проблема. Скажите кому-нибудь еще, чтобы он починил это и выполнил мое SLA». :) Если вы не знаете, какой набор навыков искал интервьюер, тогда проблема может быть в интервьюере. Младшие интервьюеры часто предполагают, что есть только один ответ (или только один правильный ответ), тогда как на самом деле существует несколько вариантов - одни лучше, чем другие, но это зависит от ситуации. Если вы уже дали свой ответ и по-прежнему видите «хмурое лицо», (вежливо) спросите их, что они искали. Вы действительно узнаете МНОГО с этим вопросом. Некоторые скажут: «Я не говорю, это мое собеседование» (командная организация, где сотрудничество не требуется). Некоторые попытаются направить вас к правильному ответу или подскажут вопрос в вопросе, что даст вам шанс выздороветь.