Гарантируется ли запись данных в файл при вызове flush java

Обновлено: 04.07.2024

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

Очищает буферы для этого потока и вызывает запись всех буферизованных данных в файл.

Перегрузки

Очищает буферы для этого потока и вызывает запись всех буферизованных данных в файл.

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

Сброс()

Очищает буферы для этого потока и вызывает запись всех буферизованных данных в файл.

Исключения

Произошла ошибка ввода-вывода.

Поток закрыт.

Примеры

Этот пример кода является частью более крупного примера, предоставленного для метода Lock.

Примечания

Этот метод переопределяет Stream.Flush.

При вызове метода FileStream.Flush буфер ввода-вывода операционной системы также очищается.

Кодер потока не сбрасывается, если вы явно не вызываете Flush или не удаляете объект. Установка для StreamWriter.AutoFlush значения true означает, что данные будут сброшены из буфера в поток, но состояние кодировщика не будет сброшено. Это позволяет кодировщику сохранять свое состояние (частичные символы), чтобы он мог правильно кодировать следующий блок символов. Этот сценарий влияет на UTF8 и UTF7, где определенные символы могут быть закодированы только после того, как кодировщик получит соседний символ или символы.

Поскольку буфер может использоваться как для чтения, так и для записи, Flush() выполняет следующие две функции:

Все данные, ранее записанные в буфер, копируются в файл, и буфер очищается, за исключением состояния кодировщика.

Если BufferedStream.CanSeek имеет значение true и данные были ранее скопированы из файла в буфер для чтения, текущая позиция в файле уменьшается на количество непрочитанных байтов в буфере. Затем буфер очищается.

Используйте перегрузку метода Flush(Boolean), если вы хотите, чтобы все буферизованные данные в буферах промежуточных файлов записывались на диск.

Этот абстрактный класс является надклассом всех классов, представляющих выходной поток байтов. Выходной поток принимает выходные байты и отправляет их в некоторый приемник.

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

Сводка конструктора

Краткое описание метода

Все методы Экземплярные методы Абстрактные методы Конкретные методы

Модификатор и тип	Метод и описание
void	close()

Методы, унаследованные от класса java.lang.Object

Сведения о конструкторе

Выходной поток

Сведения о методе

написать

Записывает указанный байт в этот выходной поток. Общий контракт для записи заключается в том, что в выходной поток записывается один байт. Записываемый байт — это восемь младших битов аргумента b. 24 старших бита b игнорируются.

Подклассы OutputStream должны обеспечивать реализацию этого метода.

написать

Записывает байты b.length из указанного массива байтов в этот выходной поток. Общий контракт для write(b) заключается в том, что он должен иметь точно такой же эффект, как и вызов write(b, 0, b.length) .

написать

Записывает len байтов из указанного массива байтов, начиная со смещения off, в этот выходной поток. Общий контракт для write(b, off, len) заключается в том, что некоторые байты массива b записываются в выходной поток по порядку; элемент b[off] — это первый записанный байт, а b[off+len-1] — последний байт, записанный этой операцией.

Метод записи OutputStream вызывает метод записи одного аргумента для каждого записываемого байта. Подклассам рекомендуется переопределять этот метод и обеспечивать более эффективную реализацию.

Если b равно null , генерируется исключение NullPointerException.

Если значение off отрицательное, или len отрицательное, или значение off+len больше, чем длина массива b , то генерируется исключение IndexOutOfBoundsException.

смыть

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

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

Метод flush для OutputStream ничего не делает.

закрыть

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

Метод close для OutputStream ничего не делает.

Обзор:
Вложенный |
Поле | |

Подробности:
Поле | |

Сообщите об ошибке или функции.
Дополнительные справочные материалы по API и документацию для разработчиков см. в документации по Java SE. Эта документация содержит более подробные описания, предназначенные для разработчиков, с концептуальными обзорами, определениями терминов, обходными путями и примерами рабочего кода.
Авторские права © 1993, 2022, Oracle и/или ее дочерние компании. Все права защищены. Использование регулируется условиями лицензии. Также ознакомьтесь с политикой распространения документации.

если я выполню socket.getOutputStream().flush(), означает ли это, что он ничего не сделает, поэтому я могу его удалить?

заранее спасибо

Ответы

Нет, это просто говорит о том, что в абстрактном классе OutputStream flush() ничего не делает. Он ничего не говорит о своих конкретных подклассах.

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

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

См. следующий метод, который записывает 100 случайных чисел в файл.
Предположим, что все 100 случайных чисел составляют 804 КБ, а 800 операций записи записали 800 байтов из 804 байтов на диск к моменту завершения цикла for. закончился. 4 все еще остаются в буфере BufferedWriter.

Теперь, если метод 'flush' не вызывается, эти оставшиеся байты не записываются на диск и просто теряются. Это может привести к чему угодно, будь то поврежденный zip-файл, записанный на диск, поврежденный текстовый файл и т. д.

DynamicBasics пишет:
Если в последнем не вызывается метод flush, то если в выходном потоке есть какие-то оставшиеся байты, они теряются и не записываются на диск.

Это может произойти. Нет никакой гарантии, что это будет. Первый вызов close() также вызывает flush(). Во-вторых, нет ничего, что могло бы помешать буферизованному Stream или Writer очиститься по собственному желанию.

Конечно, тот факт, что это может произойти, является достаточной причиной, чтобы настаивать на вызове функции flush() или, по крайней мере, close().

Если вы вообще используете Writer с zip-файлом, вы почти наверняка будете повреждены в любом случае. Писатели предназначены только для текста.

Хорошо, но у меня всегда были сомнения: зачем вообще иметь flush в API? Почему бы API не позаботиться о том, чтобы все сбрасывалось при закрытии или что-то в этом роде?

Я всегда чувствовал следующее -

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

DynamicBasics пишет:
Хорошо, но у меня всегда были сомнения: зачем вообще иметь flush в API? Почему бы API не позаботиться о том, чтобы все сбрасывалось при закрытии или что-то в этом роде?

Он сбрасывается при закрытии. API позаботится об этом.

Иногда вам просто может понадобиться сбросить() без закрытия, например, когда вы записали достаточно данных и хотите отправить их, не дожидаясь, пока буфер очистится.
Тем не менее, программисту редко приходится вызывать flush() самостоятельно.

Да, это то, что мне любопытно, кто-нибудь когда-нибудь считал необходимым использовать flush в каком-то своем коде? Или это то, что флеш выставлен API, но бесполезен!

Это не бесполезно, просто это не часто нужно программисту. В зависимости, конечно, от типа вещей, которые делает программа.
Если у вас есть простое «прочитать все данные из точки А и записать данные в точку Б», это не нужно.
Если вы отправляете сообщения туда и обратно между точкой А и точкой Б, вы можете очищать буфер после каждого сообщения.

Каяман пишет:
Если вы отправляете сообщения туда и обратно между точкой А и точкой Б, вы можете очищать буфер после каждого сообщения.

Речь идет о разделении. Когда вы пишете код, который записывает в OutputStream, лучше, чтобы этот код не делал предположений о типе OutputStream, например, буферизуется он или нет.

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

Как я уже сказал, close() вызывает flush(). Однако иногда этого недостаточно. Например, если у вас есть долгоживущее сетевое соединение. Вы отправляете какие-то данные и еще не готовы закрыть соединение, но хотите, чтобы данные были отправлены как можно скорее, поэтому вызываете flush().

Я всегда чувствовал следующее -

или
программистам действительно нужно сбросить промежуточный уровень, и я не понимаю, когда требуется такое действие.
< /p>

В Java-программе (java 1.5) у меня есть BufferedWriter, обертывающий Filewriter, и я много раз вызываю write(). Полученный файл довольно большой. Среди строк этого .

Если я просто вызову функцию close() в выходном потоке, вывод будет гарантирован, или мне нужно всегда вызывать flush()?

Я использую File.createTempFile для создания обычных файлов, которые хочу сохранить. Причина, по которой я использую этот метод, заключается в том, что он гарантирует уникальное имя файла. Однако я вижу странную вещь .

Я использую JavaComm и получаю inputStream из объекта последовательного порта. У меня проблема в том, что иногда при запуске системы появляются шумовые символы в .

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

Я использую BufferedOutputStream для записи в файл. Во время отладки я заметил, что операция сброса занимает очень много времени, даже если ОС показывает, что файл получил .

PrintWriter(OutputStream out) — этот метод не выполняет автоматическую очистку строки. Этот метод выполняет автоматическую промывку линии. Мой вопрос: что такое промывка строки? Как я могу убедиться, что эти данные действительно сброшены на диск? Метода file.flush() не существует. (Обратите внимание, что я не .

Я записываю информацию в файл через DataOutputStream (RandomAccessFile->FileOutputStream->BufferedOutputStream->DataOutputStream). Я предполагаю, что если буфер, используемый для вывода данных, заполнен, то поток вывода данных будет автоматически очищаться? Причина, по которой я спрашиваю .

Поэтому, конечно, мы должны попытаться поймать, наконец, любой закрываемый ресурс. Но я наткнулся на код, который грешит следующим образом: java.util.Properties.store() .

привет, мне просто интересно, есть ли способ действительно определить конец файла. Например, У меня есть текстовый файл, содержащий данные a, a b, b c, c d, d e, e, данные должны заканчиваться символом «e», но если я поставлю 2 пробела ниже «e». Программа будет продолжаться до тех пор, пока не будут прочитаны пробелы. вот мой .

во-первых, Writer — это абстрактный класс, а close() — абстрактный, поэтому этот метод в Writer не имеет реализации. Во-вторых, если вы посмотрите на исходный код BufferedWriter (здесь, в Java 1.4.2_04) public void close() выдает IOException < synchronized (lock) < if (out == null) return; сброс буфера(); выход.закрыть(); выход = ноль; КБ = ноль; >> void flushBuffer() выдает исключение IOException < synchronized .

Здравствуйте, я реализую функцию канала оболочки unix в java. Это многопроцессорные каналы, которые связаны с потоками каналов java. Только если команды предполагают использовать входной поток (например, more, grep и т. д.), а затем читать из него другие команды, такие как ls и т. д., которым не нужен поток i/p, игнорируют его и просто записывают в .

Вы всегда можете посмотреть исходный код в src.zip. Да, flush() тоже не работает, и вы можете спокойно игнорировать как flush(), так и close(). Если вы уверены, что когда-либо захотите использовать ByteArrayOutputStream только здесь. Однако в большинстве случаев я бы порекомендовал вам выполнить функцию close(), которая также неявно выполняет функцию flush(), .

Сертифицированный Sun программист для платформы Java 2 (SCJP)
Сертифицированный Sun разработчик для платформы Java 2 (SCJD)
Сертифицированный Sun разработчик веб-компонентов для платформы Java2, Enterprise Edition ( SCWCD)
Сертифицированный Sun разработчик бизнес-компонентов для платформы Java2, Enterprise Edition (SCBCD)
Сертифицированный Sun Enterprise Architect для J2EE (SCEA)
Сертифицированный IBM корпоративный разработчик, WebSphere Studio V5.0
>

У меня есть приложение, в котором я хочу записать строку текста в поток вывода, а затем передать ее клиенту. На веб-сервере websphere 0S/390 кажется, что он не сбрасывается. Вместо этого он ожидает завершения работы сервлета. Я пытался использовать как объекты response.getOutputStream, так и response.getWriter, чтобы сделать это, но безуспешно. Я пробовал setBufferSize(0), .

В классе OutputStream есть метод flush(), который можно вызвать для сброса потока. Обратите внимание, что у InputStream нет такого метода, так как нет причин сбрасывать InputStream. Лучше всего сбрасывать явно, но в некоторых случаях Java сделает это за вас: 1) OutputStream.close() вызывает OutputStream.flush() перед закрытием потока. 2) Java.

Я пишу в BufferedOutputStream( FileOutputStream ) и хочу время от времени записывать позицию, в которой находится файловый поток. fos = новый FileOutputStream(theFile); bos = новый BufferedOutputStream(fos); FileChannel theChannel = fos.getChannel(); /* позже */ bos.write( theBytes ); если( isSomethingTrue ) < bos.flush(); storeAPosition(positionIndex++, theChannel.position()); >байты не могут быть записаны в файл в это время.

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

Я делаю сетевую программу. Итак, я трижды передаю сообщения между клиентом и сервером. 1. от клиента к серверу 2. от сервера к клиенту 3. от клиента к серверу на третьем шаге я получил исключительную ошибку: данные должны начинаться с нуля. поэтому я подумал, что проблема возникает из моего объекта чтения InputStream. Потому что он также считывает сокет на первом этапе. Спасибо.

Возможно. Является ли это гарантией того, что любой OutputStream или Writer, который явно не буферизован (т. е. в его документах не указано, что это так или нет), не буферизован? Вместо того, чтобы предполагать, я бы в таких случаях вызывал flush(). Кроме того, многие API имеют дело с абстрактными типами, поэтому вы не знаете, какова базовая реализация. Так что пока реальный практический эффект.

Единственный раз, когда вам нужно вызвать flush(), это если ВСЕ следующие условия верны: - Вы записали некоторые данные И - Вы не полностью закончили. Есть еще данные для записи. И - Вы хотите, чтобы данные, которые вы уже записали, достигли места назначения как можно скорее. Это неприемлемо, если кто-то все еще сидит в .

У меня есть класс, который действует как комбинированный сканер/парсер для интерфейса командной строки для сервера. Класс читает и записывает экземпляр класса Console, полученный вызовом System.console();. Для вывода используется PrintWriter, связанный с Консолью, полученный путем вызова метода Writer() экземпляра Консоли. В классе есть метод println, который .

<р>1. Есть сетевой форум 2. Нет возможности заставить TCP (ничего общего с java) отправлять. Посылает, когда хочет. 3. Я вообще считаю, что лучше (требование) отправлять сообщения, а не данные по сокетам. Сообщение самим своим существованием определяет свои границы (начало/конец). Это так же просто, как отправить размер до .

Это действительно так, но основные идеи в нем по-прежнему применимы. И Runtime.exec(), и ProcessBuilder являются абстракциями, которые скрывают множество специфичных для операционной системы вещей, о которых многие пользователи ничего не знают, и статья охватывает многие из них. Но у меня впечатление от исходного поста такое, что вопрос как раз о том, что переменная Process есть .

Эта ошибка неоднократно публиковалась на этом форуме, но до сих пор нет положительного ответа. В моем приложении используется Java 1.5 и веб-сервер iPlanet SUN 6.1. Когда пользователь делает многократный щелчок на любой странице запроса, возникает эта ошибка. Основываясь на моем расследовании, я получил это исключение, когда ответ сервера не может найти страницу запроса. Может любой .

Что ж, если бы это был я, я бы, вероятно, переопределил метод flush(), чтобы записывать только те байты, которые я был готов записать. Так что в вашем случае Base64 я мог бы сдержать один или два байта. Если бы меня спросили об этом, я бы просто сказал, что мой метод flush() соответствует контракту, потому что эти байты еще не были «буферизованы».

Я использую FileWriter в своем веб-приложении для регистрации событий приложения. После каждой записи я делаю сброс(). Проблема в том, что записи обычно не отображаются в файле журнала, пока я не выключу Tomcat. Если я переключаюсь с использования flush() на закрытие + повторное открытие FileWriter, это устраняет проблему, однако это кажется чрезмерным и неэффективным. я не .

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

Здравствуйте, у меня есть последовательное устройство, которое я читаю, и оно выдает 49 байт каждую секунду. Я настраиваю метод: serialEvent (событие SerialPortEvent) и неясно, как очистить буфер. первое чтение часто представляет собой полные 49 байтов, и это здорово. но если по какой-то причине выполняется частичное чтение, каждое событие доставляет только 49 байт.

У меня есть клиент, который отправляет несколько байтов на сервер с помощью DataOutputStream. Сервер получает их с помощью DataInputStream,readFully(). По какой-то причине это работает нормально, хотя я не сбрасываю каждый раз после вызова записи на стороне клиента. Когда я использую PrinWriter в том же сокете, мне приходится очищать память после каждого вызова println. Почему такая разница?

Читайте также: