Spring и ExecutorService запутался

 
 
 
Сообщения:3
Для примера, упрощенный код, который допустим что то делает....
@RestController
@Scope("prototype")
public class Test {

    @RequestMapping(value = "/test", method = RequestMethod.GET, produces = "application/json;charset=UTF-8")
    public String test() {

        ExecutorService executor = Executors.newFixedThreadPool(10);
 
        executor.submit(() -> {
                        // что то делает
                    });
        executor.submit(() -> {
                        // что то делает
                    });
      // и еще N раз сабмитим
        
        executor.shutdown();
        executor.awaitTermination(15, TimeUnit.MINUTES);
 
        
        return // какую  то строку или что угодно другое;
    }
}


когда запускаю в нетбинсе в режиме отладки проекта, вижу после первого обращения по юрл (например в этом случае localhost:8080/test), в вкладке "потоки"

pool-1-thread-1
pool-1-thread-2
отработали потоки все ок
обновляю страницу, что бы запустить еще раз выполнение этого всего и вижу

pool-2-thread-1
pool-2-thread-2

и так будет до бесконечности, как я понимаю плодится пулы... это из за того что есть жизненный цикл где увеличивается значение глобальной переменной этих пулов? или создаются и плодятся пулы, который непонятно где (для меня) потом висят и кушают ресурсы? два дня пытаюсь вычитать про это, уже чет запутался....
ps ногами по лицу не пинать, учусь... )
 
 
Сообщения:9478
Это потому что ты каждый раз создаешь пул заново. Пул он на то и нужен, чтоб его создать один раз и везде переиспользовать.
Сами пулы в твоем случае не плодятся - ты все же делаешь shutdown. Наверняка, есть какая-то статическая переменная с номерами чтоб они не повторялись.
Изменен:08 дек 2016 19:31
 
 
Сообщения:3
Настараживает это именование...

Староверъ:
Это потому что ты каждый раз создаешь пул заново. Пул он на то и нужен, чтоб его создать один раз и везде переиспользовать.

немного поподробнее можно тут, жизненный цикл этого всего дела в спринге с такими аннотациями каков будет?
Изменен:09 дек 2016 06:15
 
 
Сообщения:9478
Дак ты создаешь пул в методе и там же его тушишь. Значит жизненный цикл - этот метод (т.е. один запрос).
 
 
Сообщения:3
Староверъ:
Дак ты создаешь пул в методе и там же его тушишь. Значит жизненный цикл - этот метод (т.е. один запрос).

да я понимаю, что создаю и тут же его тушу, настораживает именование пулов, если это как вы сказали "статическая переменная с номерами", то бог с ним, главное что бы не жрало ни чего лишнего...

и еще такой вопрос
кусок кода
@RestController
@Scope("prototype")
public class Test {
 
    @RequestMapping(value = "/test", method = RequestMethod.GET, produces = "application/json;charset=UTF-8")
    public synchronized static String test() {
        
         // допустим есть какой то objList

        ExecutorService executor = Executors.newFixedThreadPool(objList.size());
        objList.stream().forEach((s) -> {
           executor.submit(() -> {
                          // что то делает с статическими объектами/либо еще чем то
                      });
        }

           executor.shutdown();
           executor.awaitTermination(15, TimeUnit.MINUTES);
        
        return // какую  то строку или что угодно другое;
    }
}


и задача например. может быть 1-2-3 ... N одновременных запросов по этому юрл
каждая задача требует выполнения в N количестве потоков в зависимости от количества объектов в objList
с учетом того что в потоке может быть работа с статическими объектами, они могут быть перезаписаны или как то потерты в ходе работы и это не потокобезопасно?
правильно я понимаю что для потокобезопасности нада synchronized static писать? Создается очередь на выполнение и будет блокировка пока не отработается предыдущий запрос?
Если это так, то можно как ускорить это? Или это кординально по другому? Где что можно почитать на эту тему желательное на русском, или "легком" для чтения английском

ps если что от называю не своими именами ссори, только начинаю писать что то на java
Изменен:09 дек 2016 07:52
 
Модераторы:wedens
Сейчас эту тему просматривают:Нет