Настройка блокирующего файла для чтения в Java

Чтобы получить гарантированно заблокированный ввод-вывод, прочитайте с консоли, например. /dev/console в Linux или CON в Windows.

Чтобы сделать эту платформу независимой, вы можете взломать FileDescriptor из FileInputStream:

    // Open a dummy FileInputStream
    File f = File.createTempFile("dummy", ".tmp");
    f.deleteOnExit();
    FileInputStream fis = new FileInputStream(f);

    // Replace FileInputStream's descriptor with stdin
    Field fd = FileInputStream.class.getDeclaredField("fd");
    fd.setAccessible(true);
    fd.set(fis, FileDescriptor.in);

    System.out.println("Reading...");
    fis.read();
    System.out.println("Complete");

ОБНОВЛЕНИЕ

Я понял, что вам даже не нужен метод для блокировки. Чтобы просто получить правильную трассировку стека, вы можете вызвать read() для недопустимого FileInputStream:

    FileInputStream fis = new FileInputStream(new FileDescriptor());
    fis.read(); // This will throw IOException exactly with the right stacktrace

Если вам все еще нужен блокирующий read(), именованные каналы — это то, что вам нужно: запустите mkfifo с помощью Runtime.exec в системах POSIX или создайте \\.\PIPE\MyPipeName в Windows.

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

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

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

Если вы хотите использовать свой собственный FileInputStream без изменения исходного кода программы или компиляции, вы можете создать собственный загрузчик классов, который загружает ваш собственный класс FileInputStream вместо реального. Вы можете указать, какой загрузчик классов использовать в командной строке:

java -Djava.system.class.loader=com.test.MyClassLoader xxx

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

Насколько я понимаю, вы хотите написать тест, который проверяет трассировку стека метода FileInputStream.read(). Что насчет потомков FileInputStream, если они переопределяют метод read()?

Если вам не нужно проверять потомков, я думаю, вы можете использовать Интерфейс JVM Tool, вставив точку останова во время выполнения в нужном методе, а в событии обработки этого события (точки останова) - дамп трассировки стека. После завершения дампа вы удаляете точку останова и продолжаете выполнение. (Все это происходит во время выполнения с использованием этого API, никакой черной магии :))

У вас может быть отдельный поток, отслеживающий изменения в файле время доступа и создать дамп потока jvm, когда это произойдет. Что касается создания дампа потока в коде, который я не пробовал, но похоже, что здесь дан ответ: Создать дамп потока Java без перезапуска.

Я не знаю, насколько хорошо это будет работать с синхронизацией между вашими потоками, но я думаю, что это должно быть довольно близко. Я также не на 100% уверен в независимости этого решения от ОС, поскольку я его не тестировал, но оно должно работать для большинства современных систем. См. javadocs в java.nio.file.attribute.BasicFileAttributes, чтобы узнать, что будет возвращено, если оно не поддерживается.

Один трюк: если можно изменить ваш API, чтобы он возвращал Reader вместо File, то вы можете обернуть строку с помощью пользовательского StringReader (скажем, class SlowAsRubyStringReader extends Reader), который переопределяет различные методы int read() с помощью Thread.sleep(500), прежде чем он сделает реальный работай. Только во время тестирования, конечно.

@см. http://docs.oracle.com/javase/7/docs/api/java/io/StringReader.html

Я думаю, что здесь есть более серьезная проблема, а не только файлы: вы хотите проверить контекст, в котором API вызывается во время ваших тестовых случаев, не так ли? То есть вы хотите иметь возможность изучить стек и сказать: «Ага! Я поймал вас на вызове MudFactory API из объекта JustTookABath, НЕВЕРОЯТНО!». Если это так, то вам, возможно, придется углубиться в динамические прокси, которые позволят вам перехватывать вызовы функций, или использовать аспектно-ориентированное программирование, которое позволяет вам делать то же самое, но более систематически. См. http://en.wikipedia.org/wiki/Pointcut.

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

Что-то типа:

log ( ExceptionUtils.getStackTrace(new Exception()) );

Документация по ExceptionUtils находится здесь: https://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/exception/ExceptionUtils.html