The two are quite different as one is pessimistic locking, and the other is optimistic locking.
For the lock(READ), there is no hole between the find() and the lock(), the lock is an optimistic lock, and does not do anything until the end of the transaction, when it will check and lock the version number of the row with the version of the object from the persistence context (which is from the find(), or even before if it were read earlier, or even merged from a different transaction).
Note, that if you are updating the object, you don't need to call lock(READ) at all, the version is always checked on update when optimistic locking is used.
The advantages of optimistic locking is that it is does not hold locks on the database until commit, allows concurrent reads, and allows a lock across transaction boundaries (if the version is merged).
The "Select for Update" is pessimistic locking, and the syntax is database specific, but most databases have some syntax. JPA 2.0 also support pessimistic locking at the JPA API level. The advantages of pessimistic locking is that once the lock is obtained, the transaction is less likely to fail from lock contention.
See,
http://en.wikibooks.org/wiki/Java_Persistence/Locking