Безопасны ли отрицательные тайм-ауты с Future.get(long, TimeUnit)?

Безопасно ли указывать отрицательный тайм-аут для java.util.concurrent.Future.get(long, TimeUnit)? В документации говорится

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

Означает ли это, что он будет работать с отрицательными значениями, или это утверждение распространяется только на неотрицательные случаи? Поведение, которое я ожидал бы, состояло бы в том, чтобы вернуть результат, если он доступен, или тайм-аут немедленно в противном случае. Такая ситуация может возникнуть, если мы хотим рассчитать таймаут для абсолютного момента времени, а он уже прошел. Конечно, я могу использовать max{timeout, 0}, но действительно ли это необходимо? Тесты в моей среде показали, что это работает, но гарантируется ли это? https://stackoverflow.com/questions/9332904/behavior-of-future-get-with-0-timeout указывает, что это должно иметь место для тайм-аута 0.

Или, говоря другими словами: предположим, что результат Future доступен. Будет ли реализация Future несовместимой, если get(long, TimeUnit), вызванный с отрицательным тайм-аутом, сделает что-то еще, кроме возврата этого результата?


java specifications java.util.concurrent
person Drunix    schedule 14.02.2014    source источник
comment
Future — это интерфейс, так что никаких гарантий вы там вряд ли получите. Нижний ответ на вопрос, на который вы ссылаетесь, показывает, что отрицательные значения обрабатываются так же, как 0 в случае FuteureTask.   -  person Keppil    schedule 14.02.2014
comment
Но интерфейс не означает, что он не имеет гарантированного поведения. Затем реализации должны соответствовать этому задокументированному поведению. Я не уверен, что интерпретация ответа на связанный вопрос также охватывает отрицательные случаи.   -  person Drunix    schedule 14.02.2014
comment
Да, это так. Вы ожидаете, что любой реализатор будет следовать ожидаемому поведению, но автор интерфейса вряд ли может это гарантировать.   -  person Keppil    schedule 14.02.2014
comment
Да, но тогда эта реализация будет несовместимой. Я добавил эту альтернативную формулировку к моему вопросу.   -  person Drunix    schedule 14.02.2014

Ответы (1)


arrow_upward
6
arrow_downward

Нельзя ждать «максимум» какое-то время; единственная теоретическая гарантия состоит в том, что время ожидания будет не меньше некоторого числа. На самом деле это указано в JLS. Поэтому формулировку следует читать следующим образом:

Пусть t — заданное время ожидания, а u — время, фактически затраченное этим методом, прежде чем вернуть управление вызывающей стороне. Тогда и только тогда, когда u ‹ t, возвращаемое значение вызова метода гарантированно будет возвращаемым значением Future.

Учитывая вышеизложенное, отрицательное значение t вполне допустимо, и все значения ‹= 0 должны вести себя точно так же.

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

Если вы впоследствии обратились в суд для урегулирования ответственности за ущерб и заинтересованы в исходе такого судебного процесса, то я считаю, что это беспокойство выходит за рамки сферы Stack Overflow.

person Marko Topolnik    schedule 14.02.2014
comment
Я уверен, что на практике это, вероятно, сработает, но мой вопрос заключается в том, действительно ли это требуется по спецификациям? На самом деле это своего рода языковой и специальный вопрос юриста. Я не уверен, что мое чтение является предполагаемым в этом случае. Люди, более знакомые с такого рода спецификациями, могут иметь более четкое представление о том, что означает это предложение. - person Drunix; 14.02.2014
comment
IllegalArgumentException было одним из возможных вариантов поведения, о котором я думал. Основываясь на вашем прогнозе того, что произойдет, если кто-то действительно реализует его по-другому, я бы сказал, что спецификация может быть неоднозначной в теоретическом смысле, но достаточно ясной для практических целей. - person Drunix; 14.02.2014
comment
Я не столько заинтересован в обращении в суд, сколько стараюсь не полагаться на неопределенное поведение. Я думаю, что ваш ответ ясно дает понять, что поведение для отрицательных значений может быть правильно выведено из утверждения. - person Drunix; 14.02.2014