Mutex avoid any concurrent access on a given block. When a thread owned the monitor lock of an object, another thread cannot own the monitor lock of that same object until the first thread releases the monitor lock.
Using Semaphore approach, you can let multiple threads to concurrently execute the business, while the maximum number of threads which can perform the simultaneous execution is limited. For an example, if we limit the maximum number of threads to 100, only 100 threads can execute the business at same time. Another thread willing to execute at the same time would have to stay in queue until one of the thread stops the execution - that limits the simultaneous access for 100 threads. Have a look at the documentation of java.util.concurrent.Semaphore class.
Actually, there are different kinds of semaphores. The ones that Dijkstra originally invented can count only to 1, and as such aren't really different from a mutex. The whole word comes from the railroad analogy, with multple trains wanting to go on the same track. The semaphore makes sure that only one train at a time goes there.
Currently the two main differences are that the semaphores can count to more than 1, and that mutexes are usually implemented as a more low-level primitive, and because of this are optimized for quick grab, do and release while semaphores are more sutiable for the long waits.