One way to create thread is to pass a object that implements Runnable Interface to a Thread constructor as mentioned in Java Multithreading Approaches (Java Concurrency - Part 1):

With regards to java concurrency, when reading some API documentation (e.g. java.util.concurrent),  there's  the term "non-blocking" and "blocking." In computer science, non-blocking means:

• Use low-level atomic hardware primitives (machine instructions) such as compare-and-set instead of intrinsic locks to ensure thread safety (data integrity under concurrent access).

• Performance gain and better scalability. threads does not have to be suspended/waken up by the OS using synchronization.
• Use non-fair locking (which does not guarantee any particular access order), which can have much more system throughput than fair-locking (which grants access to the longest-waiting thread).
  
• It doesn't cause other tasks (threads) to wait until the task is finished.
  
• Deadlock free. The risk of deadlocks is removed. No one thread will wait to get a lock held by another thread "forever". 

In Java concurrency, ForkJoinPool uses a work-stealing multi-threading framework which works well for executing tasks of uneven distribution of chunk sizes. Before you read on, you need to know Java Multithreading Approaches first.

A ForkJoinPool implements ExecutorService but it differs from other (I'll refer them as 'traditional') ExecutorService mainly by virtue of employing work-stealing - all threads in the pool attempt to find and execute subtasks created by other active tasks. It automatically balance the task load between threads, while traditional ThreadPoolExecutor has no mechanism for such kind of load balancing. If no available worker thread is available, tasks will be blocked until a thread becomes available to steal work from those workers who are busy.

In Java concurrency, there are two low level concurrency implementations in Java to create a thread - extend the Thread class or implement Runnable interface.  These basic approaches neither return value from the thread nor throw exception should anything goes wrong. There's a third approach since Java 1.5 - use Java Concurrency package which supports to receive return values from thread execution.