As the author of spymemcached, I’m a bit biased, but I’d say it’s mine for the following reasons:
Designed from scratch to be non-blocking everywhere possible.
When you ask for data, issue a set, etc… there’s one tiny concurrent queue insertion and you get a Future to block on results (with some convenience methods for common cases like get).
Optimized Aggressively
You can read more on my optimizations page, but I do whole-application optimization.
I still do pretty well in micro-benchmarks, but to compare fairly against the other client, you have to contrive unrealistic usage patterns (for example, waiting for the response on every set operation or building locks around gets to keep them from doing packet optimization).
Tested Obsessively
I maintain a pretty rigorous test suite with coverage reports on every release.
Bugs still slip in, but they’re usually pretty minor, and the client just keeps getting better. 🙂
Well Documented
The examples page provides a quick introduction, but the javadoc goes into tremendous detail.
Provides High-level Abstractions
I’ve got a Map interface to the cache as well as a functional CAS abstraction. Both binary and text support an incr-with-default mechanism (provided by the binary protocol, but rather tricky in text).
Keeps up with the Specs
I do a lot of work on the server itself, so I keep up with protocol changes.
I did the first binary protocol server implementations (both a test server and in memcached itself), and this was the first production-ready client to support it, and does so first-class.
I’ve also got support for several hash algorithms and node distribution algorithms, all of which are well-tested for every build. You can do a stock ketama consistent hash, or a derivative using FNV-1 (or even java’s native string hashing) if you want better performance.