когда поток выходит из объема?
Не могли бы вы проверить эту строку
# Define the file appender
log4j.appender.file=org.apache.log4j.FileAppender
log4j.appender.file.File=$[logs} //TODO should be ${logs}
Если я не ошибаюсь. Спасибо.
Вторая мысль:
открытый класс Log4Test2 {
private final Logger logger = LoggerFactory.getLogger("admin");
public void fefe()throws IOException,SQLException{ //try remove static
System.setProperty("logs.file", "C:\\New folder 2\\logs.log");
log.info("Debug2");
log.info("Info2");
}
3 ответа
Другой потоковый дизайн помог бы найти и зафиксировать этот вид проблемы и быть более эффективным кроме того. Это - длинноватый ответ, но сводка, "если Вы делаете потоки в Java, проверяете java.util.concurrent как можно скорее)".
Я предполагаю, что Вы - многопоточность этот код, чтобы изучить потоки, а не ускорить слова подсчета, но это - очень неэффективный способ использовать потоки. Вы создаете два потока на строку - две тысячи потоков для тысячи файлов строки. Создание потока (в современном JVMs) использует ресурсы операционной системы и является обычно довольно дорогим. Когда два - уже не говоря о две тысячи - потоки должны получить доступ к совместно используемому ресурсу (такому как Ваш chars и words счетчики), получающаяся нехватка памяти также повреждает производительность.
Создание переменных счетчика synchronized поскольку Chris Kimpton предлагает или Atomic как WMR предполагает, вероятно, исправит код, но он также сделает эффект конкуренции намного хуже. Я вполне уверен, это пойдет медленнее, чем однопоточный алгоритм.
Я предлагаю иметь всего один долговечный поток, который заботится chars, и один для words, каждый с очередью заданий, которой Вы отправляете задания каждый раз, Вы хотите добавить новое число. Таким образом, только один поток пишет в каждую переменную, и если Вы внесете изменения в дизайн, то будет более очевидно, кто ответственен за какой. Это также будет быстрее, потому что нет никакой нехватки памяти, и Вы не создаете сотни потоков в жестком цикле.
Это также важно, после того как Вы считали все строки в файле, для ожидания всех потоков для окончания перед фактическим распечатыванием значений счетчиков иначе Вы теряете обновления от потоков, которые еще не закончились. С Вашим текущим дизайном необходимо было бы создать большой список потоков, которые Вы создали и пробежали его в конце, проверяющем, что они - все мертвые. С дизайном queue-and-worker-thread можно просто сказать каждому потоку истощать свою очередь и затем ожидать, пока он не сделан.
Java (от 1,5 и) делает этот вид дизайна очень легким реализовать: выезд java.util.concurrent. Executors.newSingleThreadExecutor. Это также помогает добавить больше параллелизма позже (принимающий надлежащую блокировку и т.д.), поскольку можно просто переключиться на пул потоков, а не единственный поток.
Поскольку Chris Kimpton уже указал правильно, что у Вас есть проблема с обновлением chars и words в различных потоках. Синхронизация на this не будет работать также потому что this ссылка на текущий поток, что означает, что различные потоки будут синхронизироваться на различных объектах. Вы могли использовать дополнительный "объект блокирования", на котором можно синхронизироваться, но самый легкий способ зафиксировать это состоял бы в том, чтобы, вероятно, использовать AtomicIntegers для 2 счетчиков:
AtomicInteger chars = new AtomicInteger();
...
new Thread(new Runnable() {public void run() { chars.addAndGet(characterCounter(line));}}).start();
...
В то время как это, вероятно, решит Вашу проблему, более подробный ответ Sam Stoke является абсолютно правильным, первоначальный проект очень неэффективен.
Для ответа на вопрос о том, когда поток "выходит из объема": Вы начинаете две новых дискуссии для каждой строки в Вашем файле, и все они будут работать, пока они не достигнут конца их run() метод. Это - то, если Вы не сделаете их потоками демона), в этом случае они выйдут, как только потоки демона являются единственными, все еще работающими в этой JVM.
Походит на хороший вопрос мне... Я думаю, что проблема могла бы быть связана с атомарностью символов + = и слова + = - несколько потоков могли звонить, это одновременно - делает Вы делаете что-либо, чтобы гарантировать, что нет никакого чередования.
Это:
Распараллельте 1, имеет символы = 10, хочет добавить 5
Распараллельте 2, имеет символы = 10, хочет добавить 3
Поток 1 разрабатывает новое общее количество, 15
Поток 2 разрабатывает новое общее количество, 13
Распараллельте 1 символ наборов к 15
Распараллельте 2 символа наборов к 13.
Могло бы быть возможным, если Вы не используете, синхронизировался при обновлении их Вар.