For a long time we are seeing random problems in our Jenkins environment.
Basically this can be recognized by the message:

"There are more SCM polling activities scheduled than handled, so the threads are not keeping up with the demands. Check if your polling is hanging, and/or increase the number of threads if necessary."

We tried various settings for the numerb of threads, but nothing seems to help. Finannly we set up Oracles "Java VisualVM" to monitor our running Jenkins master.

Now we see that for every scm polling a thread is created. It is active for some seconds and then waiting for the next execution.
Sometimes there are threads that seem to be copies from existing ones, referencing the exact same "hudson.model.FreeStyleProject" object (see highlighted threads in screenshot).

I'm not sure what is the intended design for polling threads:

• create a thread for each polling job and keep it alive waiting until it's next scheduled (the settings in jenkins config would limit the total number of polling threads possible)

or

• create a thread each (scheduled) time you check for updates and kill it afterwards (the settings in jenkins config would limit the total number of alive polling threads possible in parallel)

Nevertheless both designs don't match the monitored behaviour, as a 1:1 relationship between polling thread and Job seems to mandatory anyway.