A thread can be loosely defined as a separate stream of
execution that takes place simultaneously with and independently of
everything else that might be happening. A thread is like a classic
program that starts at point A and executes until it
reaches point B. It does not have an event loop. A
thread runs independently of anything else happening in the
computer. Without threads an entire program can be held up by one
CPU intensive task or one infinite loop, intentional or otherwise.
With threads the other tasks that don't get stuck in the loop can
continue processing without waiting for the stuck task to finish.
It turns out that implementing threading is harder than implementing multitasking in an operating system. The reason it's relatively easy to implement multitasking is that individual programs are isolated from each other. Individual threads, however, are not. To return to the printing example, suppose that while the printing is happening in one thread, the user deletes a large chunk of text in another thread. What's printed? The document as it was before the deletion? The document as it was after the deletion? The document with some but not all of the deleted text? Or does the whole system go down in flames? Most often in a non-threaded or poorly threaded system, it's the latter.
Threaded environments like Java allow a thread to put locks on shared resources so that while one thread is using data no other thread can touch that data. This is done with synchronization. Synchronization should be used sparingly since the purpose of threading is defeated if the entire system gets stopped waiting for a lock to be released. The proper choice of objects and methods to synchronize is one of the more difficult things to learn about threaded programming.