You don't ask the arguably more fundamental question, "How can I have 290 processes when my CPU only has four cores?" This answer is a bit of history, which might help you understand the big picture, even though the specific question has already been answered. As such, I'm not going to give a TL;DR version.
Once upon a time (think, 1950s–'60s), computers could only do one thing at a time. They were very expensive, filled whole rooms, and we needed a way to make efficient use of them by sharing them between multiple people. The first way of doing this was batch processing, in which users would submit tasks to the computer and they'd be queued up, executed one after another and the results would be sent back to the user. That was OK but it did mean that, if you wanted to do a calculation that was going to take a couple of days, nobody else could use the computer during that time.
The next innovation (think, 1960s–'70s) was time-sharing. Now, instead of executing the whole of one task, then the whole of the next one, the computer would execute a bit of one task, then pause it and execute a bit of the next one, and so on. Thus, the computer would give the impression that it was executing multiple processes concurrently. The great advantave of this is that now you can run a calculation that will take a couple of days and, although it will now take even longer, because it keeps getting interrupted, other people can still use the machine during that time.
All of this was for huge mainframe-style computers. When personal computers started to become popular, they initially weren't very powerful and, hey, since they were personal it seemed OK for them to only be able to do one thing&nbdp;– run one application – at once (think, 1980s). But, as they became more powerful (think, 1990s to present), people wanted their personal computers to time-share, too.
So we ended up with personal computers that gave the illusion of running multiple processes concurrently by actually running them one at a time for brief periods and then pausing them. Threads are essentially the same thing: eventually, people wanted even individual processes to give the illusion of doing multiple things concurrently. At first, the application writer had to handle that themself: spend a little while updating the graphics, pause that, spend a little while calculating, pause that, spend a little while doing something else, ...
However, the operating system was already good at managing multiple processes, it made sense to extend it to manage these sub-processes, which are called threads. So, now, we have a model where every process (or application) contains at least one thread, but some contain several or many. Each of these threads corresponds to a somewhat independent subtask.
But, at the top level, the CPU is still only giving the illusion that these threads are all running at the same time. In reality, it's running one for a little bit, pausing it, choosing another to run for a little bit, and so on. Except that modern CPUs can run more than one thread at once. So, in the real reality, the operating system is playing this game of "run for a bit, pause, run something else for a bit, pause" on all the cores simultaneously. So, you can have as many threads as you (and your application designers) want but, at any moment in time, all but a few of them will actually be paused.