Чаще всего реализации отличаются от уровня возможности, например стрим апи позволяет поменять последовательную обработку в параллельную, только поменяв тип стрима, если нужно больше гибкости в настройки, берешь более низкоуровневый апи(например executor service) и тд. Поэтому вопрос что лучше не уместен
что-то вроде сервиса в который будет работать с апи фейсбук, хочу чтобы у нескольких пользователей одновременно выполнялись запросы к этому сайту
Возможно узкое место будет не столько в потоках, сколько в сети или на строне ответа facebook (он других клиентов ради одного пакетного обделять не будет). Сделай каким нибудь способом и напиши нагрузочный тест.
что-то вроде сервиса в который будет работать с апи фейсбук, хочу чтобы у нескольких пользователей одновременно выполнялись запросы к этому сайту
Хотя эта задача больше похожа, что тебе ну нужно будет управлять потоками самому, если пользователи будут вызывать твой сервис по http, вер-сервер сам будет создавать поток на вызов
Возможно узкое место будет не столько в потоках, сколько в сети или на строне ответа facebook (он других клиентов ради одного пакетного обделять не будет). Сделай каким нибудь способом и напиши нагрузочный тест.
Хотя эта задача больше похожа, что тебе ну нужно будет управлять потоками самому, если пользователи будут вызывать твой сервис по http, вер-сервер сам будет создавать поток на вызов
На текущий момент: клиент(его логин, пароль хранятся в классе) -> экземпляр класса передается в thread -> запускается поток и выполняет методы по алгоритму
что-то вроде сервиса в который будет работать с апи фейсбук, хочу чтобы у нескольких пользователей одновременно выполнялись запросы к этому сайту
Если всякие запросы надо делать, то надо какое-нибудь неблокирующее io использовать. Иначе разницы нет, что для многопоточности использовать, большую часть времени потоки будут тупо ждать ответа.
Кажется, тут ошибка в худшем времени для LinkedList. Верно? Я про вставку (O(n) должно быть, ведь итерируем по элементам, пока не найдём, куда вставить)