Are there problems with massive amounts of threads

[kammce]

What problems come with having a bunch of classes and objects with their own threads running at the same time(Game class, Player class, Item class, terrain class all have their own threads)? For example, I have an Item class that has its own thread that detects if the player has intercepted its bounding box/Rectangular area. Right now, there does not seem to be a problem because I only have two Items on the screen. But what happens when I need 50 or 100 items (hypothetically). Is there an issue with having 100 threads running at the same time or does Java have some really awesome way of handling them and I do not have to worry about the amount of threads I have running.

Thank you for listening.

[Norm]

I'm not sure what the performance hit would be with 100s of threads. I might redesign the app to use just a few threads. One thread could move all of the objects and test them all for collisions.

[Fubarable]

You will probably want to use a thread pool with a fixed number of threads so as not to overwhelm the system.

[kammce]

Hmmm, Is there a way to get one class that use the Thread of another class. I would like to know if I could get my Item class to use Game's thread but have Item invoke run() from it's class rather than code Game to invoke a method in Item using run(), if that makes sense. I am not too sure this is even possible. If not, I can always come up with something else.

[Norm]

way to get one class that use the Thread of another class.

It's not class's that use Threads, its methods.
If you call a method, that method is running on your thread. So if a method in "another class" calls a method in "one class" then that method is using the "another class"s method's thread.

[Norm]

Another way to think of the problem:
There is a continuing supply of new events that are to take place sometime in the future. If these events were wrapped in a class and put on a list ordered by the time in the future when the event is to occur, then you could have one controlling thread that services this list. It would look at the time of the next event and set a timer to restart itself when the time comes for the event to happen. When the timer calls the control program it awakens and executes all the events due to be executed at that time, then looks at the time for the next event, sets a timer to wait until the time for that event to be executed. And so on.
The event's methods would be putting new events on the queue scheduled to be executed some time in the future.

[kammce]

Another way to think of the problem:
There is a continuing supply of new events that are to take place sometime in the future. If these events were wrapped in a class and put on a list ordered by the time in the future when the event is to occur, then you could have one controlling thread that services this list. It would look at the time of the next event and set a timer to restart itself when the time comes for the event to happen. When the timer calls the control program it awakens and executes all the events due to be executed at that time, then looks at the time for the next event, sets a timer to wait until the time for that event to be executed. And so on.
The event's methods would be putting new events on the queue scheduled to be executed some time in the future.

This is what I am going with. Thank you for your help.