Кто первый встал - того и тапки

18
Недоступна

1. Разберись, что делает программа. 1.1. Каждая нить должна читать с консоли слова. Используй готовый static BufferedReader reader. 1.2. Используй AtomicInteger readStringCount, чтобы посчитать, сколько слов уже считано с консоли всеми нитями. 2. Реализуй логику метода run: 2.1. Пока нить не прерва

Вы не можете решать эту задачу, т.к. не залогинены.

Комментарии (343)

популярные
новые
старые

Для того, чтобы оставить комментарий вы должны авторизоваться

oneDollarGourmet $1

вчера, 16:38

не знаю у кого что лишнее требовалось ввести, у меня вводилось все четко - просто без одного условия не принимал валидатор - после добавления этого условия ничего не изменилось

Sergey Grebenkin Backend Developer в Sochi

11 февраля, 19:01

Интересная задачка. Главный вопрос, который у меня возник - почему после завершения потоков, какой-нибудь один все-таки заблокирован и ждет дополнительного ввода readLine(). Пока разбирался, выяснил некоторые любопытные вещи. Оказывается BufferedReader класс это Thread Safe класс - ему не надо явно ставить synchronized(). Откопал ready(), который не блокирует поток. В итоге пазл сошелся.

oneDollarGourmet $1

вчера, 16:36

что-то вы усложнили все

Вячеслав 18 уровень, Санкт-Петербург

5 февраля, 03:21

Глупый вопрос: подскажите, что это за проверка reader на готовность? Это что вроде проверки, что нет такой ситации:reader.close();? Просто раньше вроде небыло такого

Виктор 18 уровень

4 февраля, 11:17

Пока этот поток не прерывается(){
        Пробуем{
                Если (ридер.готов()){
                        В результат добавить ридер.чтениеЛинии()
                        счетчикЧтенияСтрок.гетИинкремент()
                        }
             }
    Ловим (Исключение){
                ПечатаемСтекТрейс
             }
}

Как-то так Про атомарность можно зацепить Здесь и здесь

Даниил Александрович 24 уровень, Тамбов

31 января, 10:45

метод run должен работать ни слова, что должен один раз проверить. поэтому цикл а не условие!

Leo 26 уровень, Москва

14 января, 14:02

Такой результат вышел: #1:[1, 2, 4] #2:[3, 5] #3:[] java.io.IOException: Stream closed at java.io.BufferedReader.ensureOpen(BufferedReader.java:122) at java.io.BufferedReader.ready(BufferedReader.java:444) at com.javarush.task.task16.task1628.Solution$ReaderThread.run(Solution.java:54) Но прошло)

Дмитрий 23 уровень

10 января, 18:35

Чем дальше в лес - тем толще партизаны. Мы вам ничего не объясним, но вы гуглите ... С таким же успехом можно и бесплатно погуглить

Jh-007 31 уровень, Kansk-City

5 января, 13:25

Не проверял на null ввод, из-за этого не проходила валидация. С другой стороны, откуда null может появится при вводе с консоли? Никогда бы не догадался до этого.

ivasvi 22 уровень, Санкт-Петербург

30 декабря 2020, 07:06

После обломов в предыдущих задачах потратил кучу времени в этой на то, чтобы после вывода результата программа завершалась, а не предлагал считать с консоли еще одно-два значения. А оказалось, что этого и не требуется. "Правильное решение" работает так же коряво... Смутило еще и то, что решение достаточно простое и даже на хард не тянет, если закрыть глаза на вышеописанную проблему.

Sergey Grebenkin Backend Developer в Sochi

11 февраля, 19:02

Та же проблема была. Пришлось погуглить и найти ready().

Alexandr Vlasov 19 уровень, Москва

25 декабря 2020, 13:33

Что не так с .addAndGet(1) может кто то сказать, почему с ним неправильно, а с incrementAndGet() правильно? Что то последнее время пошли задачи, когда результат какой должен быть, но потом ищешь где же не по нужному...

ivasvi 22 уровень, Санкт-Петербург

30 декабря 2020, 07:02

Есть подозрение, что валидатор просто проверяет не все возможные варианты. Будто в него по жесткому зашита проверка на наличие определенного метода. Такое уже было, когда используешь sleep(), а не Thread.sleep(). Хотя мне не ясно, чем ему простой слип не угодил, если мы его вызываем внутри объекта, унаследованного от Thread.