Use limited number of threads

[koca2000]

NoteBlockAPI 1.x uses one platform thread for each SongPlayer even when the playback has not started yet. It is not very resource effective so a different solution should be used.

@Elecast2 proposed a solution with a single-threaded ticker in PR #119. However, this solution use fixed 10ms delay which in some cases may not be precise enough and in other situations it does unnecessary work. Also it serialize SongPlayers into a queue and so e.g. an event in one of the SongPlayers may delay playback of the others.

I like the idea of the SongTicker or custom ExecutorService, but it has to be done in a way that one SongPlayer doesn't affect the others. Something like a group of worker threads and a PriorityQueue.

[matyas-toth]

I think it's more than just an enhancement, NoteBlockAPI somehow has a thread leak issue, where created async tasks turn into a sleeping phase and just doesn't end it, each async task just gets added to the thread limit infinitely.

[koca2000]

@matyas-toth Unless there is a bug I am not aware of, this is most likely caused by the plugin using the NoteBlockAPI. NoteBlockAPI 1.x from the very beginning creates a thread in constructor and keeps it until the SongPlayer is destroyed with the destroy() method or because of autoDestroy == true (don't ask me why, it was like this when I started to mantaining it). So if the plugin that uses NoteBlockAPI 1.x creates SongPlayer in advance or doesn't destroy it, the thread may stay there forever. Unfortunately, I can't easily change this behavior in 1.x e.g. by setting autoDestroy to true by default because that would most likely break a lot of plugins.

However, version 2.0, which I am working on, doesn't have this problem, because it ends the thread even when the SongPlayer is paused. Therefore I put the enhancement tag here.