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

  • 18
  • Недоступна
1. Разберись, что делает программа. 1.1. Каждая нить должна читать с консоли слова. Используй готовый static BufferedReader reader. 1.2. Используй AtomicInteger readStringCount, чтобы посчитать, сколько слов уже считано с консоли всеми нитями. 2. Реализуй логику метода run: 2.1. Пока нить не прерва
Вы не можете решать эту задачу, т.к. не залогинены.
Комментарии (343)
  • популярные
  • новые
  • старые
Для того, чтобы оставить комментарий вы должны авторизоваться
вчера, 16:38
не знаю у кого что лишнее требовалось ввести, у меня вводилось все четко - просто без одного условия не принимал валидатор - после добавления этого условия ничего не изменилось
Sergey Grebenkin Backend Developer в Sochi
11 февраля, 19:01
Интересная задачка. Главный вопрос, который у меня возник - почему после завершения потоков, какой-нибудь один все-таки заблокирован и ждет дополнительного ввода readLine(). Пока разбирался, выяснил некоторые любопытные вещи. Оказывается BufferedReader класс это Thread Safe класс - ему не надо явно ставить synchronized(). Откопал ready(), который не блокирует поток. В итоге пазл сошелся.
вчера, 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.