Для чего нужна проверка на null??

Ну я подумал, что раз вопрос к задаче определённой, то код всегда можно в ней посмотреть (речь о правильном решении которое авторы придумали). А то напугали мол правильный код публиковать нельзя, а то вопрос удалят, аккаунт заблокируют а за мной выедет чёрная машина ) ну лан рискну ))) Я чуть разбил код, а то не влезало в сообщение.

public class Solution {
    public static volatile AtomicInteger readStringCount = new AtomicInteger(0);
    public static volatile BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));

    public static void main(String[] args) throws IOException {
        //read count of strings
        int count = Integer.parseInt(reader.readLine());

        //init threads
        ReaderThread consoleReader1 = new ReaderThread();
        ReaderThread consoleReader2 = new ReaderThread();
        ReaderThread consoleReader3 = new ReaderThread();

        consoleReader1.start();
        consoleReader2.start();
        consoleReader3.start();

        while (count > readStringCount.get()) {
        }

        consoleReader1.interrupt();
        consoleReader2.interrupt();
        consoleReader3.interrupt();
        System.out.println("#1:" + consoleReader1);
        System.out.println("#2:" + consoleReader2);
        System.out.println("#3:" + consoleReader3);

        reader.close();
    }

У меня нет активной подписки, я не могу смотреть задачи. Тут кстати есть тег code в сообщениях, можно не плейн текстом кидать. Ну а по поводу кода стало чутка понятнее. У тебя три треда жрут из одного ридера. Один из них или несколько полюбому получат null в соответствии с документацией, когда файл будет вычитан. Ведь читать ты будешь до тех пор пока поток не прерван (условие while), а не до тех пор пока в файле есть что читать. Вопрос зачем именно добавили эту проверку остается открытым, потому как я не вижу чем null вместо string может навредить, но подозреваю сделано это для того, что бы не сохранять лишние null'ы в твой result

Чуть выше видно, что выполнение обрывается Interrupt методом после ввода количества строк из консоли (например 5). А я правильно понял, получается когда я ввожу строку с консоли, 3 потока её пытаются прочитать и записать в свой результат, кто первый тот прочитал, а остальные двое наверное получают null? По факту удаление проверки на null никак не меняет поведение программы, но валидатор перестаёт принимать код. Я разбил код на 2 части, чтобы он целиком влез. Вверху код отредактировал.

public static class ReaderThread extends Thread {
        private List<String> result = new ArrayList<String>();

        public void run() {
            String string;
            try {
                while (!Thread.currentThread().isInterrupted()) {
                    if ((string = reader.readLine()) != null) {
                        result.add(string);
                        readStringCount.incrementAndGet();
                    }
                }
            } catch (IOException e) {
                e.printStackTrace();
            }
        }

        @Override
        public String toString() {
            return result.toString();
        }
    }
}

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

Влезу со своим длинныйм пятачком 1. "По факту удаление проверки на null никак не меняет поведение программы, но валидатор перестаёт принимать код." - мы не знаем, какой программой валидатор проверяет твою задачу. Во многих задачах валидатор не твой мейн запускает и смотрит на результат, а свой собственный. Поэтому нельзя с уверенностью сказать, что если у нас удаление проверки на нуль ничего не меняет, тоже самое происходит и у валидатора. У него может что-то менять. 2. "если мы знаем, что 2 других метода 100% получат нулл" - опять-таки, мы не можем это знать. Мы можем допустить, что так оно и есть. А такие допущения - это как раз и основной источник багов и дырок. Ты не можешь быть на 100% уверен, если не проверил сам

Я проверил, не получают другие нити null... я просто пытаюсь представить хоть один сценарий, при котором введённая строка могла бы оказаться null.. и не могу...

Вся сложность работы с потоками в том, что фактическое управление ими есть только у джава машины. Ты можешь послать сигнал interrupt хоть сто раз, когда его воспринять решит джава машина. По этому здесь, когда три отдельных потока пытаются организованно кушать из одного источника у нас нет никаких гарантий что не случится хрень. Даже не смотря на волатильный AtomicInteger каутер и такой же ридер. Даже то как ты посылаешь сигналы о прерывании - это три последовательных команды. Ты уверен что применив одну из них два других потока не успеют отработать? А уверен что третий остановится? :) В прочем такие корнеркейсы руками выявить и правда бывает сложным. Именно для такого и существуют тесты, коими валидатор и является. Если твое решение он не пропустил значит какой-то из тестов упал. Если на результат прохода валидатора влияет проверка на null, значит null таки где-то вылазит.

"Ты уверен что применив одну из них два других потока не успеют отработать?" - я ж студент чайник плохо понимающий как это работает )) был уверен ага )))) в общем пока я понял, что всё что попадает в BufferedReader особенно в несколько потоков не плохо бы проверять на null, более ясное понимание видать придёт в будущем, спасибо за объяснения)

попробуй ввести Ctrl+Z или Ctrl+D чтобы получить нулл или \u001a

Спасибо ))) Сработало только CTRL + D, но ход твоих мыслей мне нравится :-) я получил null ыы)) теперь везде его буду посылать и крашить программы)))) \u001a - нашел только такое описание: 26 U+001A 1A Control character: Substitute не знаю что он делал, но идею понял, передать в качестве строки спецсимвол конца строки ))))) тогда ридер на самом деле получит null, сам бы я не допёр до такой мысли. Однако реализовать это не смог. Как я не пытался ввести спецсимвол, и слеш ставил и кавычки, idea всё экранирует, корректо обрабатывает и печатает потом точно так, как было введено. Если только валидатором можно как то передать спецсимвол... Я прям так и вижу как бухгалтер вводит "\u001a - а потом: "ОЙ Я ЧТО ТО НАЖАЛА И ОНО САМО ВСЁ СЛОМАЛОСЬ" )))) ctrl+d - дублирование строки же? получается строки нет, а мы её продублировали? потому null посылается? ctrl+z не делает ничего - отмена введённого текста же? почему она должна была послать нулл?

Ctrl+D - это дублирование строки в идее. в терминале же это посылает какой-то специальный символ. аналогично и с Ctrl+Z: в самом редакторе будет одно поведение, а в другой программе - может быть совершенно другое поведение. честно говоря я сам не в курсе. просто зашел в интернет и погуглил про EOF (End Of File) символ в джаве а чтобы вот такое \u001a вводить одним символом - там как-то через нумпад-клавиатуру это делается вроде) у меня на ноуте ее нет, так что я даже не подскажу как это сделать)) можете в интернете поискать

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