va1eb: Нужно смотреть что это за "connectionPool"... Если это реализация DatSource, например получаемая из томката, или org.apache.commons.dbcp.BasicDataSource... То вызов метода close возвратит коннекшен обратно в пул. А если человек как то напрямую работает с пулом, то тут нужно бить по рукам
В итоге сплита, вы получаете массив строк состоящих из пробела и числа. Из-за пробела, у вас parseInt кидает ошибку, которую вы успешно гасите и не видите из-за чего не парсится часть чисел.
По дефолту, в джаве, массив приметивного типа, например int инициализируется нулями
MOWS: ну так однозначного решение нет, все зависит от того что это за объекты, как затратно их создавать и т.д. Может некоторые объекты не затратно создавать каждый раз при запросе, некоторые могут не иметь состояния и их можно создать один раз и использовать для всех запросов, для некоторых можно использовать threadlocal и т.д.
Можно конечно все методы сделать синхронными, но тогда все потоки будут блокироваться, и ждать завершения одного потока
Если закрыть глаза на то, что "countRequest++" , не атомарная операция, то да, в конце в лог выведется "100". Метод getCalcSumm параллельно будет вызван 100 потоками и они будут дожидаться завершения метода. Например, если у вас в этом методе есть запрос в БД, то будет выполнено параллельно 100 запросов
