Сериализация Java, ObjectInputStream.readObject(), проверьте, будет ли блокироваться

Я использую ObjectInputStream для вызова readObject для чтения в сериализованном Objects. Я хотел бы избежать блока этого метода, поэтому я хочу использовать что-то вроде Inputstream.available().

InputStream.available() сообщит вам, что байты доступны и что read() не будет блокироваться. Есть ли эквивалентный метод для сериализации, который сообщит вам, есть ли доступные Object и readObject не будет блокироваться?


java serialization nonblocking
person Mike    schedule 01.10.2009    source источник

Ответы (4)


arrow_upward
8
arrow_downward

Нет. Хотя вы можете использовать ObjectInputStream в другом потоке и проверить, есть ли в нем доступный объект. Как правило, опрос — не лучшая идея, особенно с плохими гарантиями InputStream.available.

person Tom Hawtin - tackline    schedule 01.10.2009

arrow_upward
5
arrow_downward

API сериализации Java не предназначен для поддержки функции available(). Если вы реализуете свои собственные функции чтения/записи объектов, вы можете считывать любой объем данных из потока, который вам нравится, и нет никакого метода создания отчетов.

Таким образом, readObject() не знает, сколько данных он будет считывать, поэтому он не знает, сколько объектов доступно.

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

person David Crawshaw    schedule 01.10.2009

arrow_upward
0
arrow_downward

У меня есть идея, что, добавив еще один InputStream в цепочку, можно сделать информацию о доступности доступной для чтения клиентом:

ВЗЛОМАТЬ!

InputStream is = ... // where we actually read the data
BufferedInputStream bis = new BufferedInputStream(is);
ObjectInputStream ois = new ObjectInputStream(bis);

if( bis.available() > N ) {
  Object o = ois.readObject();
}

Сложность заключается в значении N. Оно должно быть достаточно большим, чтобы охватить как заголовок сериализации, так и данные объекта. Если они сильно различаются, не повезло.

person Vladimir Dyuzhev    schedule 01.10.2009
comment
Если они вообще разнятся, то можно крупно проиграть. Если вы выберете N, который больше, чем следующий объект, вы можете попасть в состояние тупика, когда вы ожидаете больше, чем текущий объект, и отправитель не отправит следующий объект, пока вы не ответите на предыдущий. . Прежде чем использовать этот подход, убедитесь, что существует бесконечный запас входных данных! - person PanCrit; 28.11.2009

arrow_upward
0
arrow_downward

У меня работает BufferedInputStream, и почему бы просто не проверить if(bis.available() > 0) вместо значения N, это отлично работает для меня. Я думаю, что ObjectInputStream.readObject блокирует (= ждет до тех пор, пока) когда ввод не будет прочитан. Поэтому, если в потоке вообще есть какие-либо входные данные, то есть if(bis.available() > 0), ObjectInputStream.readObject не будет блокироваться. Имейте в виду, что ObjectInputStream.readObject может вызвать исключение ClassNotFoundException, и для меня это не проблема.

person TjenWellens    schedule 29.06.2011