如果是搞应用程序的程序员，就不应该使用这两种方法中的任何一种。两种都太底层了，建议使用 java.util.concurrent.locks ， 毕竟类库的就是让你多快好省的写代码。
park 直接操作线程，线程作为参数直接传入，线程会sleep知道调用了 unpark 方法。这种操作需要明确知道那个线程需要 block/unblock。可以使用 java.util.concurrent.locks.LockSupport 完成操作。
park 操作可以理解为Thread.sleep 操作，不会释放锁资源，使用不当会造成死锁。park 操作能够设置一个 blocker，并通过 getBlocker 获取阻塞的信息，方便做一些调试之类的工作。
wait 操作会释放锁。wait 操作必须在同步语句块。如果不在同步语句块会抛出 IllegalMonitorStateException 异常。使用 notify 和 notifyAll 唤醒线程。
It all eventually makes its way down to the OS’s scheduler, which hands out timeslices to processes and threads.
sleep(n) says “I’m done with my timeslice, and please don’t give me another one for at least n milliseconds.” The OS doesn’t even try to schedule the sleeping thread until requested time has passed.
yield() says “I’m done with my timeslice, but I still have work to do.” The OS is free to immediately give the thread another timeslice, or to give some other thread or process the CPU the yielding thread just gave up.
wait() says “I’m done with my timeslice. Don’t give me another timeslice until someone calls notify().” As with sleep(), the OS won’t even try to schedule your task unless someone calls notify() (or one of a few other wakeup scenarios occurs).
Threads also lose the remainder of their timeslice when they perform blocking IO and under a few other circumstances. If a thread works through the entire timeslice, the OS forcibly takes control roughly as if yield() had been called, so that other processes can run.
You rarely need yield(), but if you have a compute-heavy app with logical task boundaries, inserting a yield() might improve system responsiveness (at the expense of time — context switches, even just to the OS and back, aren’t free). Measure and test against goals you care about, as always.