Thread

Привет ! :)
Имам такова сървърче, което слуша на порт ...

while (listening) {
new ServerThread(serverSocket.accept()).start();
}

когато някой се закачи, създава се нова нишка, която после си умира

Въпросът ми е дали мъртвите нишки хабят някакъв ресурс и ако да - как мога да го рециклирам ?

не, не хабят ресурси. след като им свърши run() метода, GC се погрижва за тях като за всеки друг обект който не се използва повече. т.е. достатъчно е да не държиш reference към него и паметта и ресурсите ще се освободят

Obache socket habi resource i trjabva da se zatvarja sus close(). Tova e ulovkata v sluchaja.

s po-zdrav
pESHO

Да кажем, че хабят ресурси... Иначе щеше да е прекалено хубаво... Другото е така :)

аа, аз сокета си го затварям после

иначе ... да свиквам с мисълта за мъртвите нишки и, че не мога да направя много повече ...?

Можеш да си направиш pool от нишки.

помисли и за скорост на работа обаче, идеята на поол-а не е да спести ресурси (точно обратното той заема повече), но ти спестява време за правене на нова нишка (което е бавно ако ти идват много клиенти няма да сколасаш), друг трик е да пуснеш няколко нишки да чакат на акцепт-а.

всъщност времето ми е по-важно...
...и при това положение трябва да видя как се прави Thread pool

>> идеята на поол-а не е да спести ресурси (точно обратното той заема повече)

Това до много голяма степен зависи от начина по който ще имплементираш въпросния pool...

дето се вика , няма далавера да имаш поол от ресурси дето са по-малко от колкото ти трябват, и скороста от синхронизация на достъпа ще се увеличи .... иначе е напълно възможно на теория,
може би на прима виста не се сещам за използваемост на такова нещо

thread-pool не се ли ползва когато ще се обработват много обекти паралелно от отделни тредове. Т.е. имаме обект имаме тред.
Да кажем, че става въпрос за 1000000 обекта. Същото количество тредове не е за препоръчване (ако въобще може да се създадат). В такъв случай се прави thread-pool в който да има около 15 треда които да се занимават с това.

Ако някой се сеща друго приложение на thread-pool освен това да свирка. Аз за друго се не сещам (т.е. не е оправдано) (Не казвам, че няма, просто сега се не сещам)

По принцип съм съгласен с теб. Мисълта ми беше, че нищо не пречи например размерът на въпросния pool да бъде плаващ... Не е нужно винаги да имаш точно 30 нишки да речем.

Най-честата причина си мисля аз е когато имаш да изпълняваш купища малки таскове, за изпълнението на които просто не си зъслужава да създаваш постоянно тредове. Пример може да е изпълняването на заявки които идват от UDP - имаш 20 треда пул и един които просто ги пуска към тях.

[линк]

Benefits of Thread Pooling
Thread pooling saves the virtual machine the work of creating brand new threads for every
short-lived task. In addition, it minimizes overhead associated with getting a thread started and
cleaning it up after it dies. By creating a pool of threads, a single thread from the pool can be
recycled over and over for different tasks.
With the thread pooling technique, you can reduce response time because a thread is already
constructed and started and is simply waiting for its next task. In the case of an HTTP server,
an available thread in the pool can deliver each new file requested. Without pooling, a brand
new thread would have to be constructed and started before the request could be serviced.
Another characteristic of the thread pools discussed in this chapter is that they are fixed in size
at the time of construction. All the threads are started, and then each goes into a wait state
(which uses very few processor resources) until a task is assigned to it. This fixed size characteristic
holds the number of assigned tasks to an upper limit. If all the threads are currently
assigned a task, the pool is empty. New service requests can simply be rejected or can be put
into a wait state until one of the threads finishes its task and returns itself to the pool. In the
case of an HTTP server, this limit prevents a flood of requests from overwhelming the server to
the point of servicing everyone very slowly or even crashing. You can expand on the designs
presented in this chapter to include a method to support growing the size of the pool at runtime
if you need this kind of dynamic tuning.

Благодаря пак
явно ще трябва да е pool !
... при мен са много таскове, които се изпълняват за кратко, но често ...
и така оставт стотици трупове на нишки