Что такое 🤓
Ответ:
FileChannel.transferTo(long position, long count, WritableByteChannel target) — высокоэффективный метод для копирования данных из файла в другой канал (например, в сокет) в режиме ядра, без перекачки данных в пользовательское пространство.
Используется для оптимизации веб-серверов (отправка статических файлов) — так называемый zero-copy. Метод transferFrom() — аналогично для копирования в файл.
Работает не полностью zero-copy на всех ОС, но значительно быстрее, чем побайтовое чтение/запись.
#собеседование
transferTo в FileChannel? Ответ:
Используется для оптимизации веб-серверов (отправка статических файлов) — так называемый zero-copy. Метод transferFrom() — аналогично для копирования в файл.
Работает не полностью zero-copy на всех ОС, но значительно быстрее, чем побайтовое чтение/запись.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
История технологии сегодня — 9 июня
ℹ️ Кто родился в этот день
Джордж Стефенсон (англ. George Stephenson; 9 июня 1781, Уилэм, графство Нортамберленд — 12 августа 1848, Честерфилд, графство Дербишир) — английский изобретатель, инженер-механик. Всемирную известность приобрёл благодаря изобретённому им паровозу. Считается одним из «отцов» железных дорог. Стефенсон предложил использовать железные рельсы (вместо чугунных), а подушки, которые в дальнейшем превратились в шпалы, делать деревянными.
Иоганн Готтфрид Га́лле (нем. Johann Gottfried Galle; 9 июня 1812, Радис — 10 июля 1910, Потсдам) — немецкий астроном. 23 сентября 1846 года получил письмо от У. Леверье с просьбой провести поиск заурановой планеты по предвычисленным им координатам. В тот же вечер Галле отыскал новую планету, получившую позже название Нептун. В его честь названы кратер на Луне и кратер на Марсе, кольцо Нептуна и астероид № 2097 (Галле).
🌐 Знаковые события
1959 — на воду спущена первая подводная лодка с баллистическими ракетами на борту — американская «Джордж Вашингтон».
#Biography #Birth_Date #Events #09июня
Джордж Стефенсон (англ. George Stephenson; 9 июня 1781, Уилэм, графство Нортамберленд — 12 августа 1848, Честерфилд, графство Дербишир) — английский изобретатель, инженер-механик. Всемирную известность приобрёл благодаря изобретённому им паровозу. Считается одним из «отцов» железных дорог. Стефенсон предложил использовать железные рельсы (вместо чугунных), а подушки, которые в дальнейшем превратились в шпалы, делать деревянными.
Иоганн Готтфрид Га́лле (нем. Johann Gottfried Galle; 9 июня 1812, Радис — 10 июля 1910, Потсдам) — немецкий астроном. 23 сентября 1846 года получил письмо от У. Леверье с просьбой провести поиск заурановой планеты по предвычисленным им координатам. В тот же вечер Галле отыскал новую планету, получившую позже название Нептун. В его честь названы кратер на Луне и кратер на Марсе, кольцо Нептуна и астероид № 2097 (Галле).
1959 — на воду спущена первая подводная лодка с баллистическими ракетами на борту — американская «Джордж Вашингтон».
#Biography #Birth_Date #Events #09июня
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Раздел 11. Работа с файлами, I/O и сетью (NIO.2)
Глава 1. Классический Java I/O (java.io)
Проблема производительности побайтового ввода/вывода. Идея буфера
Побайтовое чтение или запись через
Рассмотрим детальный путь одного вызова read():
Подготовка параметров в регистрах процессора. JVM помещает файловый дескриптор и адрес буфера в регистры.
Инструкция syscall или sysenter. Процессор переключается в привилегированный режим, сохраняя состояние userspace.
Обработка в ядре ОС. Ядро проверяет валидность дескриптора, ищет страницу в page cache, при промахе (page fault) инициирует чтение с диска.
Копирование данных. Ядро копирует данные из page cache в нативный буфер userspace.
Возврат в userspace. Восстановление состояния регистров, возврат управления JVM.
Копирование в heap. JNI-код копирует данные из нативного буфера в массив
Для одного байта этот цикл избыточен в 1000 раз. Файл размером 1 MB требует 1 048 576 таких циклов. При стоимости 500 нс на вызов общее время составляет 524 мс только на системные вызовы, без учета фактического чтения данных.
Демонстрация: копирование 1 MB побайтово
Ожидаемый результат на современном оборудовании: 500-2000 мс для 1 MB. Причина не в скорости диска (современные SSD читают 1 MB за 2-5 мс), а в накладных расходах системных вызовов.
Путь данных в памяти при побайтовом чтении
Каждый вызов
Критический недостаток: page cache работает со страницами 4KB. Чтение одного байта из файла загружает целую страницу в page cache. При последовательном побайтовом чтении каждый следующий байт попадает в уже загруженную страницу, но системный вызов все равно выполняется. Page cache эффективен, но syscall-ов слишком много.
#Java #для_новичков #beginner #IO #NIO #BufferedInputStream
Глава 1. Классический Java I/O (java.io)
Проблема производительности побайтового ввода/вывода. Идея буфера
Побайтовое чтение или запись через
InputStream.read() и OutputStream.write(int) кажутся простыми и интуитивными, но скрывают фундаментальную проблему: каждый вызов инициирует полный цикл системного вызова операционной системы. Этот цикл включает переключение контекста процессора из userspace в kernelspace, выполнение кода ядра, и обратное переключение. Стоимость этого цикла на современных процессорах составляет 100-1000 наносекунд, что на порядки превышает стоимость чтения байта из оперативной памяти.Рассмотрим детальный путь одного вызова read():
Подготовка параметров в регистрах процессора. JVM помещает файловый дескриптор и адрес буфера в регистры.
Инструкция syscall или sysenter. Процессор переключается в привилегированный режим, сохраняя состояние userspace.
Обработка в ядре ОС. Ядро проверяет валидность дескриптора, ищет страницу в page cache, при промахе (page fault) инициирует чтение с диска.
Копирование данных. Ядро копирует данные из page cache в нативный буфер userspace.
Возврат в userspace. Восстановление состояния регистров, возврат управления JVM.
Копирование в heap. JNI-код копирует данные из нативного буфера в массив
byte[] в heap.Для одного байта этот цикл избыточен в 1000 раз. Файл размером 1 MB требует 1 048 576 таких циклов. При стоимости 500 нс на вызов общее время составляет 524 мс только на системные вызовы, без учета фактического чтения данных.
Демонстрация: копирование 1 MB побайтово
public class ByteByByteCopy {
public static void copyByteByByte(String source, String dest) throws IOException {
long start = System.nanoTime();
int totalBytes = 0;
try (FileInputStream fis = new FileInputStream(source);
FileOutputStream fos = new FileOutputStream(dest)) {
int byteValue;
// Каждая итерация = полный цикл системного вызова
while ((byteValue = fis.read()) != -1) {
fos.write(byteValue); // Еще один системный вызов на запись
totalBytes++;
}
}
long duration = (System.nanoTime() - start) / 1_000_000;
System.out.printf("Copied %d bytes in %d ms (byte-by-byte)%n", totalBytes, duration);
}
public static void main(String[] args) throws IOException {
// Создание тестового файла 1 MB
byte[] oneMB = new byte[1024 * 1024];
new Random().nextBytes(oneMB);
try (FileOutputStream fos = new FileOutputStream("source.bin")) {
fos.write(oneMB);
}
// Побайтовое копирование
copyByteByByte("source.bin", "dest_byte_by_byte.bin");
}
}Ожидаемый результат на современном оборудовании: 500-2000 мс для 1 MB. Причина не в скорости диска (современные SSD читают 1 MB за 2-5 мс), а в накладных расходах системных вызовов.
Путь данных в памяти при побайтовом чтении
Каждый вызов
read() создает уникальный путь через память:Поток выполнения:
[Java-код: read()]
-> [JVM: нативный метод read0()]
-> [JNI: переход в нативный код]
-> [Ядро ОС: syscall read(fd, buf, 1)]
-> [Page Cache: поиск страницы 4KB]
-> [При промахе: чтение с диска в page cache]
-> [Копирование: 1 байт из page cache в нативный буфер]
-> [Возврат в userspace]
-> [JNI: копирование 1 байта в heap]
-> [Java: возврат int]
Критический недостаток: page cache работает со страницами 4KB. Чтение одного байта из файла загружает целую страницу в page cache. При последовательном побайтовом чтении каждый следующий байт попадает в уже загруженную страницу, но системный вызов все равно выполняется. Page cache эффективен, но syscall-ов слишком много.
#Java #для_новичков #beginner #IO #NIO #BufferedInputStream
👍4
Идея буфера: чтение и запись блоками
Буферизация решает проблему, заменяя множество мелких системных вызовов на один крупный. Вместо чтения одного байта за раз, приложение запрашивает блок данных — обычно 4KB, 8KB или 64KB — одним системным вызовом, а затем извлекает байты из блока в памяти без обращения к ОС.
Математика выигрыша
Для файла 1 MB:
Побайтово: 1 048 576 системных вызовов чтения + 1 048 576 вызовов записи = 2 097 152 syscall
Буфер 4KB: 256 системных вызовов чтения + 256 вызовов записи = 512 syscall
Сокращение: в 4096 раз
Ожидаемые результаты для 1 MB файла на SSD:
128 bytes: ~50 ms
512 bytes: ~15 ms
4096 bytes: ~5 ms
8192 bytes: ~4 ms
65536 bytes: ~4 ms
Выигрыш снижается после 8KB, так как это типичный размер страницы ОС и размер блока файловой системы. Большие буферы не дают дополнительного выигрыша, но увеличивают потребление памяти в heap.
Путь данных в памяти при буферизованном чтении
Роль garbage collector и памяти
Буфер в Eden space
Массив
Если метод вызывается в цикле обработки множества файлов, буфер может быть повышен до survivor space или даже old generation при частом выделении других объектов.
#Java #для_новичков #beginner #IO #NIO #BufferedInputStream
Буферизация решает проблему, заменяя множество мелких системных вызовов на один крупный. Вместо чтения одного байта за раз, приложение запрашивает блок данных — обычно 4KB, 8KB или 64KB — одним системным вызовом, а затем извлекает байты из блока в памяти без обращения к ОС.
Математика выигрыша
Для файла 1 MB:
Побайтово: 1 048 576 системных вызовов чтения + 1 048 576 вызовов записи = 2 097 152 syscall
Буфер 4KB: 256 системных вызовов чтения + 256 вызовов записи = 512 syscall
Сокращение: в 4096 раз
public class BufferedCopy {
public static void copyWithBuffer(String source, String dest, int bufferSize)
throws IOException {
long start = System.nanoTime();
int totalBytes = 0;
// Буфер создается в heap Eden space
// Для bufferSize = 4096: 4KB массив, быстро собирается GC если не переиспользуется
byte[] buffer = new byte[bufferSize];
try (FileInputStream fis = new FileInputStream(source);
FileOutputStream fos = new FileOutputStream(dest)) {
int bytesRead;
// Каждая итерация = один системный вызов на чтение блока
while ((bytesRead = fis.read(buffer)) != -1) {
fos.write(buffer, 0, bytesRead); // Один системный вызов на запись блока
totalBytes += bytesRead;
}
}
long duration = (System.nanoTime() - start) / 1_000_000;
System.out.printf("Copied %d bytes in %d ms (buffer=%d bytes)%n",
totalBytes, duration, bufferSize);
}
public static void main(String[] args) throws IOException {
// Тест с разными размерами буфера
int[] sizes = {128, 512, 1024, 4096, 8192, 65536};
for (int size : sizes) {
copyWithBuffer("source.bin", "dest_" + size + ".bin", size);
}
}
}Ожидаемые результаты для 1 MB файла на SSD:
128 bytes: ~50 ms
512 bytes: ~15 ms
4096 bytes: ~5 ms
8192 bytes: ~4 ms
65536 bytes: ~4 ms
Выигрыш снижается после 8KB, так как это типичный размер страницы ОС и размер блока файловой системы. Большие буферы не дают дополнительного выигрыша, но увеличивают потребление памяти в heap.
Путь данных в памяти при буферизованном чтении
Первая итерация read(buffer[4096]):
[Java-код: read(buffer)]
-> [JVM: нативный метод readBytes()]
-> [JNI: переход в нативный код]
-> [Ядро ОС: syscall read(fd, buf, 4096)]
-> [Page Cache: поиск страниц, загрузка при необходимости]
-> [Копирование: 4096 байт из page cache в нативный буфер]
-> [Возврат в userspace]
-> [JNI: копирование 4096 байт в buffer[4096] в heap]
-> [Java: возврат 4096]
Вторая итерация read(buffer[4096]):
[Java-код: read(buffer)]
-> [JVM: нативный метод readBytes()]
-> [JNI: переход в нативный код]
-> [Ядро ОС: syscall read(fd, buf, 4096)]
-> [Page Cache: страницы уже в кэше]
-> [Копирование: 4096 байт]
-> [Возврат]
-> [JNI: копирование 4096 байт в buffer в heap]
-> [Java: возврат 4096]
// Всего 256 итераций для 1 MB вместо 1 048 576
Роль garbage collector и памяти
Буфер в Eden space
Массив
byte[], созданный как буфер, размещается в Eden space young generation. Если метод copyWithBuffer вызывается редко, буфер собирается при следующем minor GC. Если метод вызывается в цикле обработки множества файлов, буфер может быть повышен до survivor space или даже old generation при частом выделении других объектов.
// Антипаттерн: создание буфера внутри цикла
for (String file : files) {
byte[] buffer = new byte[8192]; // Создание при каждой итерации
copyFile(file, buffer);
// buffer становится мусором, GC собирает его
}
#Java #для_новичков #beginner #IO #NIO #BufferedInputStream
👍4
Этот код создает множество короткоживущих массивов, нагружая GC. Правильный подход — переиспользование:
ThreadLocal для многопоточности
В многопоточном приложении совместное использование одного буфера требует синхронизации.
Память: N потоков * 8KB = N * 8KB в heap на протяжении жизни потоков. Это компромисс между памятью и производительностью. Буферы в
Humongous objects и G1 GC
Буферы размером более половины размера G1-региона (обычно > 512KB для региона 1MB) считаются humongous objects. Они размещаются в специальных humongous-регионах old generation и не перемещаются при minor GC.
Это увеличивает фрагментацию heap и может вызвать преждевременный full GC.
BufferedInputStream: встроенная буферизация
Java предоставляет готовую обертку
При чтении
Путь данных с
Первый
Второй
8193-й
Массив
#Java #для_новичков #beginner #IO #NIO #BufferedInputStream
// Паттерн: переиспользование буфера
byte[] buffer = new byte[8192]; // Один буфер на все итерации
for (String file : files) {
copyFile(file, buffer); // Передача по ссылке, без создания
}
// Буфер живет до выхода из метода, собирается одним GC
ThreadLocal для многопоточности
В многопоточном приложении совместное использование одного буфера требует синхронизации.
ThreadLocal предоставляет каждому потоку свой буфер, устраняя contention:public class ThreadLocalBuffer {
// Каждый поток получает свой буфер 8KB
private static final ThreadLocal<byte[]> BUFFER =
ThreadLocal.withInitial(() -> new byte[8192]);
public void copyFileThreadSafe(String source, String dest) throws IOException {
byte[] buffer = BUFFER.get(); // Буфер потока, без синхронизации
try (FileInputStream fis = new FileInputStream(source);
FileOutputStream fos = new FileOutputStream(dest)) {
int bytesRead;
while ((bytesRead = fis.read(buffer)) != -1) {
fos.write(buffer, 0, bytesRead);
}
}
// Буфер остается в ThreadLocal, не собирается GC между вызовами
}
}Память: N потоков * 8KB = N * 8KB в heap на протяжении жизни потоков. Это компромисс между памятью и производительностью. Буферы в
ThreadLocal живут долго и могут быть повышены в old generation, что увеличивает размер heap, но устраняет аллокации в hot path.Humongous objects и G1 GC
Буферы размером более половины размера G1-региона (обычно > 512KB для региона 1MB) считаются humongous objects. Они размещаются в специальных humongous-регионах old generation и не перемещаются при minor GC.
Это увеличивает фрагментацию heap и может вызвать преждевременный full GC.
// Потенциально проблематично: 1MB буфер как humongous object
byte[] largeBuffer = new byte[1024 * 1024];
// Предпочтительнее: несколько итераций с 8KB буфером
byte[] smallBuffer = new byte[8192];
for (int i = 0; i < 128; i++) { // 128 * 8KB = 1MB
fis.read(smallBuffer);
// Обработка
}
BufferedInputStream: встроенная буферизация
Java предоставляет готовую обертку
BufferedInputStream, которая инкапсулирует логику буферизации: // Внутреннее устройство BufferedInputStream
public class BufferedInputStream extends FilterInputStream {
protected volatile byte[] buf; // Буфер в heap
protected int count; // Количество доступных байт
protected int pos; // Текущая позиция чтения
protected int markpos = -1; // Позиция маркера
// Конструктор по умолчанию: buf = new byte[8192]
public BufferedInputStream(InputStream in) {
this(in, 8192);
}
}
При чтении
BufferedInputStream сначала проверяет, есть ли данные в buf. Если есть — возвращает байт из буфера без системного вызова. Если буфер пуст — выполняет fill(), который читает до buf.length байт из underlying потока одним системным вызовом.// Использование: прозрачная буферизация
try (BufferedInputStream bis = new BufferedInputStream(
new FileInputStream("source.bin"))) {
int byteValue;
// Чтение выглядит побайтовым, но фактически буферизовано
while ((byteValue = bis.read()) != -1) {
processByte(byteValue);
}
}
Путь данных с
BufferedInputStream:Первый
read(): fill() читает 8192 байт в buf (heap), возвращает buf[0]Второй
read(): возвращает buf[1] из heap, системный вызов отсутствует8193-й
read(): буфер пуст, fill() выполняет новый системный вызовМассив
buf создается при конструировании и живет до закрытия потока. GC не вовлечен в цикл чтения.#Java #для_новичков #beginner #IO #NIO #BufferedInputStream
👍4
Что выведет код?
#Tasks
import java.io.*;
public class Task090626 {
public static void main(String[] args) throws IOException {
PrintWriter pw = new PrintWriter("out.txt");
pw.print("Hello");
try (BufferedReader br = new BufferedReader(new FileReader("out.txt"))) {
System.out.println(br.readLine());
}
}
}
#Tasks
👍3
👍3
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯7
Что такое 🤓
Ответ:
DirectByteBuffer — это класс, который выделяет память вне кучи (off-heap), напрямую через операционную систему.
Такая память не управляется GC (но объект-буфер — в куче).
Преимущества:
1) эффективный ввод-вывод (можно передать ядру без копирования).
2) снижение нагрузки на GC.
3) работа с большими блоками памяти.
Недостатки:
сложность управления (ручное освобождение через Cleaner или sun.misc.Unsafe).
Используется в NIO, Netty, Cassandra. Утечки off-heap памяти могут привести к OutOfMemoryError типа "Direct buffer memory".
#собеседование
DirectByteBuffer и off-heap memory? Ответ:
Такая память не управляется GC (но объект-буфер — в куче).
Преимущества:
1) эффективный ввод-вывод (можно передать ядру без копирования).
2) снижение нагрузки на GC.
3) работа с большими блоками памяти.
Недостатки:
сложность управления (ручное освобождение через Cleaner или sun.misc.Unsafe).
Используется в NIO, Netty, Cassandra. Утечки off-heap памяти могут привести к OutOfMemoryError типа "Direct buffer memory".
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Let's Encrypt присоединился к санкциям
https://news.ycombinator.com/item?id=48453275#48465754
Тревожных новостей вам с утра, для тех кто в теме🧑💻
https://news.ycombinator.com/item?id=48453275#48465754
Тревожных новостей вам с утра, для тех кто в теме
Please open Telegram to view this post
VIEW IN TELEGRAM
История технологии сегодня — 10 июня
ℹ️ Кто родился в этот день
Юджин Ньюмен Паркер (англ. Eugene Newman Parker; 10 июня 1927, Хоутон, Мичиган — 15 марта 2022) — американский учёный, астроном и астрофизик, известный своими работами по физике плазмы и физике Солнца. Основные труды — в области физики плазмы и её приложений к проблемам астрофизики и геофизики. Исследовал решения уравнений движения для бесстолкновительной плазмы, ускорение быстрых частиц и магнитную аннигиляцию в солнечных вспышках, образование солнечных пятен и природу магнитного поля Солнца, распространение ударных волн в межпланетном пространстве, происхождение и структуру галактических магнитных полей, происхождение и распространение галактических космических лучей. Выполнил пионерские работы по изучению свойств солнечного ветра и его взаимодействия с геомагнитным полем.
Э́двард О́сборн Уи́лсон (англ. Edward Osborne Wilson; 10 июня 1929, Бирмингем, штат Алабама, США — 26 декабря 2021) — американский биолог, социобиолог, мирмеколог, эколог, писатель, дважды лауреат Пулитцеровской премии. Был признанным в мире экспертом по муравьям и получил прозвище Ant Man. Автор более 30 книг и более 430 научных статей, некоторые из которых являются наиболее цитируемыми в истории и изданы в таких важных научных журналах, как Nature или Science. Его работы «Character displacement», опубликованная в 1956 году в соавторстве с Уильямом Брауном-младшим, «The Theory of Island Biogeography», подготовленная вместе с Робертом МакАртуром в 1967 году, «Experimental zoogeography of islands: the colonization of empty islands», изданная в 1969 году вместе Дэниелом Симберлоффом и его книги «The Insect Societies» и «Sociobiology: The New Synthesis» были удостоены награды Science Citation Classic, самой значимой награды, которая определяет наиболее цитируемые научные работы. Он также получил более 150 престижных наград и медалей по всему миру, а также более 40 почётных докторских степеней. Он является почётным членом более 30 всемирно известных и престижных организаций, академий и институтов. Его приглашали читать лекции в более чем 100 университетов и институтов по всему миру.
🌐 Знаковые события
1943 — американский торговец Милтон Рейнольдс запатентовал в США шариковую ручку, изобретённую венгром Ласло Биро.
1996 — корпорация Intel выпустила процессор Pentium II.
#Biography #Birth_Date #Events #10июня
Юджин Ньюмен Паркер (англ. Eugene Newman Parker; 10 июня 1927, Хоутон, Мичиган — 15 марта 2022) — американский учёный, астроном и астрофизик, известный своими работами по физике плазмы и физике Солнца. Основные труды — в области физики плазмы и её приложений к проблемам астрофизики и геофизики. Исследовал решения уравнений движения для бесстолкновительной плазмы, ускорение быстрых частиц и магнитную аннигиляцию в солнечных вспышках, образование солнечных пятен и природу магнитного поля Солнца, распространение ударных волн в межпланетном пространстве, происхождение и структуру галактических магнитных полей, происхождение и распространение галактических космических лучей. Выполнил пионерские работы по изучению свойств солнечного ветра и его взаимодействия с геомагнитным полем.
Э́двард О́сборн Уи́лсон (англ. Edward Osborne Wilson; 10 июня 1929, Бирмингем, штат Алабама, США — 26 декабря 2021) — американский биолог, социобиолог, мирмеколог, эколог, писатель, дважды лауреат Пулитцеровской премии. Был признанным в мире экспертом по муравьям и получил прозвище Ant Man. Автор более 30 книг и более 430 научных статей, некоторые из которых являются наиболее цитируемыми в истории и изданы в таких важных научных журналах, как Nature или Science. Его работы «Character displacement», опубликованная в 1956 году в соавторстве с Уильямом Брауном-младшим, «The Theory of Island Biogeography», подготовленная вместе с Робертом МакАртуром в 1967 году, «Experimental zoogeography of islands: the colonization of empty islands», изданная в 1969 году вместе Дэниелом Симберлоффом и его книги «The Insect Societies» и «Sociobiology: The New Synthesis» были удостоены награды Science Citation Classic, самой значимой награды, которая определяет наиболее цитируемые научные работы. Он также получил более 150 престижных наград и медалей по всему миру, а также более 40 почётных докторских степеней. Он является почётным членом более 30 всемирно известных и престижных организаций, академий и институтов. Его приглашали читать лекции в более чем 100 университетов и институтов по всему миру.
1943 — американский торговец Милтон Рейнольдс запатентовал в США шариковую ручку, изобретённую венгром Ласло Биро.
1996 — корпорация Intel выпустила процессор Pentium II.
#Biography #Birth_Date #Events #10июня
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
[Совет по Java #048]
Тема:
Проблема: Метод
Нельзя полагаться на его выполнение для освобождения критических ресурсов (файловые дескрипторы, сокеты, соединения с БД).
Кроме того,
Решение: Для явного освобождения ресурсов реализуйте интерфейс
Объяснение:
Он никогда не должен использоваться в production-коде.
#Java #советы
Тема:
finalize() — устаревший и непредсказуемый.Проблема: Метод
finalize() вызывается сборщиком мусора в неопределенный момент времени (возможно, никогда). Нельзя полагаться на его выполнение для освобождения критических ресурсов (файловые дескрипторы, сокеты, соединения с БД).
Кроме того,
finalize() имеет серьезные проблемы производительности: объекты с переопределенным finalize() требуют минимум двух циклов GC для удаления, что увеличивает нагрузку. Он также может быть вызван на объекте, который снова становится достижимым (resurrection), создавая хаос. Начиная с Java 9, finalize() помечен как deprecated. Использование его для очистки ресурсов — антипаттерн, ведущий к утечкам и непредсказуемому поведению.Решение: Для явного освобождения ресурсов реализуйте интерфейс
AutoCloseable и используйте try-with-resources. Для нестандартных сценариев (освобождение памяти native, очистка после объектов, которые могут быть забыты) используйте java.lang.ref.Cleaner (Java 9+), который предоставляет предсказуемый механизм регистрации очистки, но не гарантирует немедленного выполнения. Cleaner использует слабые ссылки и вызывается в специальном потоке. Однако лучший подход — всегда явное управление ресурсами через close().public class FinalizeVsCleaner {
//Антипаттерн: finalize (deprecated)
@Deprecated
static class BadResource {
private final FileInputStream stream;
BadResource(String path) throws IOException {
this.stream = new FileInputStream(path);
}
@Override
protected void finalize() throws Throwable {
stream.close(); // Неизвестно, когда и будет ли вызвано!
}
}
//Решение: AutoCloseable + try-with-resources
static class GoodResource implements AutoCloseable {
private final FileInputStream stream;
GoodResource(String path) throws IOException {
this.stream = new FileInputStream(path);
}
public void doWork() { /* ... */ }
@Override
public void close() throws IOException {
if (stream != null) stream.close();
}
}
// Cleaner для критических native-ресурсов (Java 9+)
static class NativeResource implements AutoCloseable {
private final Cleaner cleaner = Cleaner.create();
private final Cleaner.Cleanable cleanable;
private final long nativeHandle;
NativeResource(long handle) {
this.nativeHandle = handle;
this.cleanable = cleaner.register(this, new CleanupAction(handle));
}
private static class CleanupAction implements Runnable {
private final long handle;
CleanupAction(long handle) { this.handle = handle; }
@Override
public void run() {
freeNativeMemory(handle); // native-функция
}
}
@Override
public void close() {
cleanable.clean(); // явный вызов
}
private static native void freeNativeMemory(long handle);
}
}Объяснение:
finalize() объявлен deprecated с Java 9 и будет удален в будущих версиях. Он никогда не должен использоваться в production-коде.
AutoCloseable обеспечивает детерминированное освобождение ресурсов через try-with-resources, что гарантирует закрытие даже при исключениях. Cleaner — это замена finalize() для ситуаций, где ресурс может быть пропущен (например, native-память), но он не должен заменять явный close(). Cleaner использует фоновый поток и не дает гарантий времени вызова.#Java #советы
👍4
Что выведет код?
#Tasks
public class Task100626 {
static class Resource implements AutoCloseable {
@Override
public void close() {
throw new RuntimeException("Close exception");
}
}
public static void main(String[] args) {
try (Resource r = new Resource()) {
throw new IllegalArgumentException("Try exception");
} catch (Exception e) {
System.out.println(e.getClass().getSimpleName());
Throwable[] suppressed = e.getSuppressed();
if (suppressed.length > 0) {
System.out.println(suppressed[0].getClass().getSimpleName());
}
}
}
}#Tasks
👍2
Что такое 🤓
Ответ:
SoftReference — тип ссылки, при котором объект будет удалён сборщиком мусора только в случае нехватки памяти, перед тем как будет выброшено OutOfMemoryError.
Идеально для реализации кэшей — кэш будет хранить объекты, пока есть свободная память, и автоматически очищаться при её дефиците.
В сочетании с ReferenceQueue можно отслеживать удаление объектов и выгружать их из кэша.
Это проще, чем LRU-алгоритмы, но даёт меньший контроль.
Применяется в кэшах библиотек, загрузчиках изображений.
#собеседование
SoftReference и как его использовать для кэша? Ответ:
Идеально для реализации кэшей — кэш будет хранить объекты, пока есть свободная память, и автоматически очищаться при её дефиците.
В сочетании с ReferenceQueue можно отслеживать удаление объектов и выгружать их из кэша.
Это проще, чем LRU-алгоритмы, но даёт меньший контроль.
Применяется в кэшах библиотек, загрузчиках изображений.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
История технологии сегодня — 11 июня
ℹ️ Кто родился в этот день
Жак-Ив Кусто́ (фр. Jacques-Yves Cousteau; 11 июня 1910, Сент-Андре-де-Кюбзак, Бордо, Франция — 25 июня 1997, Париж, Франция) — французский исследователь Мирового океана, фотограф, режиссёр, изобретатель, автор множества книг и фильмов. Являлся членом Французской академии. Известен как Капитан Кусто (фр. Commandant Cousteau). Совместно с Эмилем Ганьяном в 1943 году разработал и испытал акваланг. В его честь назван уступ Кусто на Плутоне. Кусто стал создателем водонепроницаемых камер и осветительных приборов, а также изобрёл первую подводную телевизионную систему.
Шарль Фабри́ (фр. Marie Paul Auguste Charles Fabry; 11 июня 1867, Марсель — 11 декабря 1945, Париж) — французский физик, открывший вместе с Анри Буиссоном[нем.] озоновый слой атмосферы и один из изобретателей интерферометра Фабри — Перо.
🌐 Знаковые события
1991 — фирма «Microsoft» выпустила операционную систему MS DOS 5.0.
2008 — на орбиту запущен космический гамма-телескоп Fermi.
#Biography #Birth_Date #Events #11июня
Жак-Ив Кусто́ (фр. Jacques-Yves Cousteau; 11 июня 1910, Сент-Андре-де-Кюбзак, Бордо, Франция — 25 июня 1997, Париж, Франция) — французский исследователь Мирового океана, фотограф, режиссёр, изобретатель, автор множества книг и фильмов. Являлся членом Французской академии. Известен как Капитан Кусто (фр. Commandant Cousteau). Совместно с Эмилем Ганьяном в 1943 году разработал и испытал акваланг. В его честь назван уступ Кусто на Плутоне. Кусто стал создателем водонепроницаемых камер и осветительных приборов, а также изобрёл первую подводную телевизионную систему.
Шарль Фабри́ (фр. Marie Paul Auguste Charles Fabry; 11 июня 1867, Марсель — 11 декабря 1945, Париж) — французский физик, открывший вместе с Анри Буиссоном[нем.] озоновый слой атмосферы и один из изобретателей интерферометра Фабри — Перо.
1991 — фирма «Microsoft» выпустила операционную систему MS DOS 5.0.
2008 — на орбиту запущен космический гамма-телескоп Fermi.
#Biography #Birth_Date #Events #11июня
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Раздел 11. Работа с файлами, I/O и сетью (NIO.2)
Глава 1. Классический Java I/O (java.io)
BufferedInputStream – буферизованное чтение. Путь данных через память JVM
Ключевое архитектурное решение — разделение ответственности.
Внутреннее устройство
Поля
Механика fill() и путь данных
Метод
Путь данных при
Проверка состояния буфера. Определение, можно ли читать с начала или требуется сдвиг/расширение.
Системный вызов read().
Копирование в heap. Данные из нативного буфера через JNI попадают в
Обновление счетчиков.
Путь данных в памяти: детальный разбор
Сценарий: первое чтение после создания
Путь данных для первого
Массив
Сценарий: последующие чтения из буфера
Никаких системных вызовов, никакого JNI, никакого обращения к ядру. Данные извлекаются из массива в heap напрямую JVM-байткодом. Это на порядки быстрее, чем побайтовое чтение через
Сценарий: буфер исчерпан
#Java #для_новичков #beginner #IO #NIO #BufferedInputStream
Глава 1. Классический Java I/O (java.io)
BufferedInputStream – буферизованное чтение. Путь данных через память JVM
BufferedInputStream — декоратор над InputStream, добавляющий внутреннюю буферизацию к любому underlying потоку. Он не является самостоятельным источником данных, а служит промежуточным слоем, который накапливает данные в памяти и выдает их порциями при запросе. Это устраняет главный недостаток побайтового чтения: накладные расходы системных вызовов.Ключевое архитектурное решение — разделение ответственности.
FileInputStream отвечает за взаимодействие с ОС и файловой системой. BufferedInputStream отвечает за оптимизацию паттерна доступа: замену множества мелких запросов на несколько крупных. Это классический применение паттерна декоратора в Java I/O.Внутреннее устройство
// Упрощенная структура из OpenJDK
public class BufferedInputStream extends FilterInputStream {
// Внутренний буфер в heap JVM
protected volatile byte[] buf;
// Количество байт, фактически доступных в буфере
protected int count;
// Текущая позиция чтения в буфере
protected int pos;
// Позиция маркера для mark/reset, -1 если не установлен
protected int markpos = -1;
// Максимальное количество байт, читаемых после mark
protected int marklimit;
// Конструкторы
public BufferedInputStream(InputStream in) {
this(in, 8192); // Размер по умолчанию
}
public BufferedInputStream(InputStream in, int size) {
super(in);
if (size <= 0) {
throw new IllegalArgumentException("Buffer size <= 0");
}
buf = new byte[size]; // Выделение в heap
}
}
Поля
buf, count, pos образуют кольцевой буфер (ring buffer), хотя в стандартной реализации используется линейный массив с сдвигом при исчерпании. При вызове read() BufferedInputStream сначала проверяет pos < count. Если условие истинно — байт возвращается из buf[pos++] без системного вызова. Если ложно — выполняется fill(), который читает новый блок данных из underlying потока.Механика fill() и путь данных
Метод
fill() — сердце буферизации. Он выполняется, когда внутренний буфер исчерпан:// Упрощенная логика fill()
private void fill() throws IOException {
byte[] buffer = getBufIfOpen();
if (markpos < 0) {
// Маркер не установлен — читаем с начала буфера
pos = 0;
} else if (pos >= buffer.length) {
// Позиция достигла конца буфера
if (markpos > 0) {
// Сдвигаем данные от markpos к началу
int sz = pos - markpos;
System.arraycopy(buffer, markpos, buffer, 0, sz);
pos = sz;
markpos = 0;
} else if (buffer.length >= marklimit) {
// Буфер превысил лимит маркера — сбрасываем
markpos = -1;
pos = 0;
} else {
// Расширяем буфер
int nsz = pos * 2;
if (nsz > marklimit) nsz = marklimit;
byte[] nbuf = new byte[nsz];
System.arraycopy(buffer, 0, nbuf, 0, pos);
buf = nbuf;
buffer = nbuf;
markpos = 0;
}
}
count = pos;
// Системный вызов: чтение из underlying потока
int n = getInIfOpen().read(buffer, pos, buffer.length - pos);
if (n > 0) count = n + pos;
}
Путь данных при
fill():Проверка состояния буфера. Определение, можно ли читать с начала или требуется сдвиг/расширение.
Системный вызов read().
getInIfOpen().read(buffer, pos, len) — один вызов для чтения до buffer.length - pos байт.Копирование в heap. Данные из нативного буфера через JNI попадают в
buf в heap.Обновление счетчиков.
count устанавливается в количество фактически прочитанных байт.Путь данных в памяти: детальный разбор
Сценарий: первое чтение после создания
try (BufferedInputStream bis = new BufferedInputStream(
new FileInputStream("data.bin"), 8192)) {
int firstByte = bis.read(); // Инициирует fill()
}
Путь данных для первого
read():[Java: bis.read()]
-> [BufferedInputStream: pos=0, count=0, буфер пуст]
-> [fill()]
-> [FileInputStream.read(buf, 0, 8192)]
-> [JNI: нативный readBytes]
-> [Ядро ОС: syscall read(fd, native_buf, 8192)]
-> [Page Cache: поиск/загрузка страниц]
-> [Копирование: 8192 байт из page cache в native_buf]
-> [Возврат в userspace]
-> [JNI: копирование 8192 байт в buf[8192] в heap]
-> [BufferedInputStream: count=8192, pos=0]
-> [Возврат buf[0] как int]
Массив
buf[8192] создан при конструировании BufferedInputStream и размещен в heap. Для размера 8192 байт это обычный объект, не humongous. Он размещается в Eden space young generation.Сценарий: последующие чтения из буфера
int secondByte = bis.read(); // pos=1, count=8192, системный вызов отсутствует
int thirdByte = bis.read(); // pos=2, count=8192, системный вызов отсутствует
[Java: bis.read()]
-> [BufferedInputStream: pos < count? 1 < 8192 — да]
-> [Возврат buf[1] как int, pos++]
Никаких системных вызовов, никакого JNI, никакого обращения к ядру. Данные извлекаются из массива в heap напрямую JVM-байткодом. Это на порядки быстрее, чем побайтовое чтение через
FileInputStream.Сценарий: буфер исчерпан
// После 8192 вызовов read()
int byte8193 = bis.read(); // pos=8192, count=8192, буфер пуст
[Java: bis.read()]
-> [BufferedInputStream: pos < count? 8192 < 8192 — нет]
-> [fill()]
-> [System.arraycopy при необходимости]
-> [FileInputStream.read(buf, 0, 8192)]
-> [Новый системный вызов]
-> [count=новое_значение, pos=0]
-> [Возврат buf[0]]
#Java #для_новичков #beginner #IO #NIO #BufferedInputStream
👍4
Роль garbage collector
Жизненный цикл буфера
Буфер
Проблема: большой буфер и humongous objects
При размере буфера 1MB и размере G1-региона 1MB массив становится humongous object. Он размещается в специальных humongous-регионах old generation и не перемещается при minor GC. Это увеличивает фрагментацию heap и может вызвать преждевременный full GC.
Рекомендация: использовать стандартный размер 8KB или увеличивать до 64KB для последовательного чтения больших файлов. Размеры более 256KB редко дают выигрыш из-за размера страницы ОС (4KB) и размера блока файловой системы (4KB).
Проблема: утечка ссылки на поток
Если ссылка на
mark() и reset(): семантика и память
Если количество прочитанных байт после
Расширение буфера при активном маркере:
Это единственный сценарий, где
Практический пример: сравнение производительности
Ожидаемые результаты на SSD:
#Java #для_новичков #beginner #IO #NIO #BufferedInputStream
Жизненный цикл буфера
public void processFile(String path) throws IOException {
// buf создается в Eden space при конструировании BufferedInputStream
try (BufferedInputStream bis = new BufferedInputStream(
new FileInputStream(path))) {
int b;
// Цикл без аллокаций в heap — GC не вовлечен
while ((b = bis.read()) != -1) {
processByte(b);
}
} // close() вызывается автоматически
// buf становится недостижимым
// GC собирает buf и bis при следующей minor collection
}Буфер
buf — это долгоживущий объект относительно метода. Он создается при входе в try и живет до выхода. Если метод вызывается часто, буфер может быть повышен в survivor space или old generation при выживании нескольких minor GC. Это нормально — буфер небольшой (8KB) и не создает проблем с памятью.Проблема: большой буфер и humongous objects
// Потенциально проблематично: 1MB буфер
BufferedInputStream bis = new BufferedInputStream(fis, 1024 * 1024);
При размере буфера 1MB и размере G1-региона 1MB массив становится humongous object. Он размещается в специальных humongous-регионах old generation и не перемещается при minor GC. Это увеличивает фрагментацию heap и может вызвать преждевременный full GC.
Рекомендация: использовать стандартный размер 8KB или увеличивать до 64KB для последовательного чтения больших файлов. Размеры более 256KB редко дают выигрыш из-за размера страницы ОС (4KB) и размера блока файловой системы (4KB).
Проблема: утечка ссылки на поток
// Антипаттерн: утечка ссылки
private InputStream leakedStream;
public void open(String path) throws IOException {
leakedStream = new BufferedInputStream(new FileInputStream(path));
// Если исключение позже — поток не закрыт, buf не освобожден
}
Если ссылка на
BufferedInputStream сохраняется в поле класса, GC не может освободить буфер даже после исчерпания потока. Буфер остается в памяти до тех пор, пока объект BufferedInputStream достижим. При многократном открытии файлов без закрытия это приводит к исчерпанию heap.mark() и reset(): семантика и память
BufferedInputStream поддерживает маркировку позиции для последующего возврата. Это требует хранения данных в буфере между mark() и reset():bis.mark(1024); // Запомнить позицию, лимит 1024 байт вперед
// Чтение до 1024 байт
bis.reset(); // Вернуться к отмеченной позиции
Если количество прочитанных байт после
mark() превышает marklimit, маркер инвалидируется. Если данные влезают в текущий буфер — reset() работает без системных вызовов. Если требуется больше данных, чем вмещает буфер — fill() выполняет System.arraycopy для сдвига или расширяет буфер.Расширение буфера при активном маркере:
// Из fill(): буфер расширяется до marklimit
byte[] nbuf = new byte[nsz]; // Новый массив в heap
System.arraycopy(buffer, 0, nbuf, 0, pos); // Копирование старых данных
buf = nbuf; // Старая ссылка на массив теряется, GC собирает старый buf
Это единственный сценарий, где
BufferedInputStream создает новые массивы в процессе работы. При отсутствии mark()/reset() буфер остается неизменным.Практический пример: сравнение производительности
public class BufferedPerformanceDemo {
private static final int FILE_SIZE = 10 * 1024 * 1024; // 10 MB
public static void main(String[] args) throws IOException {
// Создание тестового файла
createTestFile("test.bin", FILE_SIZE);
// Тест 1: FileInputStream без буферизации
measure("FileInputStream raw", () -> {
try (FileInputStream fis = new FileInputStream("test.bin")) {
while (fis.read() != -1) {} // Побайтово
}
});
// Тест 2: FileInputStream с внешним буфером
measure("FileInputStream + byte[]", () -> {
try (FileInputStream fis = new FileInputStream("test.bin")) {
byte[] buf = new byte[8192];
while (fis.read(buf) != -1) {}
}
});
// Тест 3: BufferedInputStream (внутренняя буферизация)
measure("BufferedInputStream", () -> {
try (BufferedInputStream bis = new BufferedInputStream(
new FileInputStream("test.bin"))) {
while (bis.read() != -1) {} // Побайтово, но буферизовано
}
});
}
private static void measure(String name, Runnable task) {
long start = System.nanoTime();
task.run();
long ms = (System.nanoTime() - start) / 1_000_000;
System.out.printf("%s: %d ms%n", name, ms);
}
private static void createTestFile(String path, int size) throws IOException {
byte[] data = new byte[size];
new Random().nextBytes(data);
try (FileOutputStream fos = new FileOutputStream(path)) {
fos.write(data);
}
}
}Ожидаемые результаты на SSD:
FileInputStream raw: 15 000-30 000 msFileInputStream + byte[]: 30-50 msBufferedInputStream: 30-50 msBufferedInputStream с побайтовым read() достигает той же производительности, что и FileInputStream с внешним массивом, но с более чистым API. Внешний буфер требует ручного управления размером и границами, BufferedInputStream инкапсулирует эту сложность.#Java #для_новичков #beginner #IO #NIO #BufferedInputStream
👍4
Что выведет код?
#Tasks
import java.io.*;
public class Task110626 {
public static void main(String[] args) throws IOException {
byte[] data = {10, 20, 30, 40, 50};
BufferedInputStream bis = new BufferedInputStream(new ByteArrayInputStream(data));
bis.mark(2);
System.out.print(bis.read());
System.out.print(bis.read());
System.out.print(bis.read());
bis.reset();
System.out.print(bis.read());
}
}
#Tasks
👍2