1. Разберись, что делает программа.
1.1. Каждая нить должна читать с консоли слова. Используй готовый static BufferedReader reader.
1.2. Используй AtomicInteger readStringCount, чтобы посчитать, сколько слов уже считано с консоли всеми нитями.
2. Реализуй логику метода run:
2.1. Пока нить не прерва
Кто первый встал - того и тапки
- 18
- Недоступна
Комментарии (343)
- популярные
- новые
- старые
Для того, чтобы оставить комментарий вы должны авторизоваться
oneDollarGourmet $1
вчера, 16:38
не знаю у кого что лишнее требовалось ввести, у меня вводилось все четко - просто без одного условия не принимал валидатор - после добавления этого условия ничего не изменилось
0
Sergey Grebenkin Backend Developer в Sochi
11 февраля, 19:01
Интересная задачка.
Главный вопрос, который у меня возник - почему после завершения потоков, какой-нибудь один все-таки заблокирован и ждет дополнительного ввода readLine().
Пока разбирался, выяснил некоторые любопытные вещи. Оказывается BufferedReader класс это Thread Safe класс - ему не надо явно ставить synchronized(). Откопал ready(), который не блокирует поток. В итоге пазл сошелся.
0
oneDollarGourmet $1
вчера, 16:36
что-то вы усложнили все
0
Вячеслав 18 уровень, Санкт-Петербург
5 февраля, 03:21
Глупый вопрос:
подскажите, что это за проверка reader на готовность? Это что вроде проверки, что нет такой ситации:reader.close();?
Просто раньше вроде небыло такого
0
Виктор 18 уровень
4 февраля, 11:17
Здесь и здесь
Как-то так
Про атомарность можно зацепить 0
Даниил Александрович 24 уровень, Тамбов
31 января, 10:45
метод run должен работать
ни слова, что должен один раз проверить.
поэтому цикл а не условие!
0
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)
Но прошло)
0
Дмитрий 23 уровень
10 января, 18:35
Чем дальше в лес - тем толще партизаны.
Мы вам ничего не объясним, но вы гуглите ...
С таким же успехом можно и бесплатно погуглить
+3
Jh-007 31 уровень, Kansk-City
5 января, 13:25
Не проверял на null ввод, из-за этого не проходила валидация. С другой стороны, откуда null может появится при вводе с консоли? Никогда бы не догадался до этого.
+4
ivasvi 22 уровень, Санкт-Петербург
30 декабря 2020, 07:06
После обломов в предыдущих задачах потратил кучу времени в этой на то, чтобы после вывода результата программа завершалась, а не предлагал считать с консоли еще одно-два значения. А оказалось, что этого и не требуется. "Правильное решение" работает так же коряво...
Смутило еще и то, что решение достаточно простое и даже на хард не тянет, если закрыть глаза на вышеописанную проблему.
+1
Sergey Grebenkin Backend Developer в Sochi
11 февраля, 19:02
Та же проблема была. Пришлось погуглить и найти ready().
0
Alexandr Vlasov 19 уровень, Москва
25 декабря 2020, 13:33
Что не так с .addAndGet(1) может кто то сказать, почему с ним неправильно, а с incrementAndGet() правильно?
Что то последнее время пошли задачи, когда результат какой должен быть, но потом ищешь где же не по нужному...
0
ivasvi 22 уровень, Санкт-Петербург
30 декабря 2020, 07:02
Есть подозрение, что валидатор просто проверяет не все возможные варианты. Будто в него по жесткому зашита проверка на наличие определенного метода. Такое уже было, когда используешь sleep(), а не Thread.sleep(). Хотя мне не ясно, чем ему простой слип не угодил, если мы его вызываем внутри объекта, унаследованного от Thread.
0