There is no one answer to this, largely because it's not always true. In fact, arguably it's never really true. You can't measure the speed of a language, only the speed of some particular implementation (and rarely even of the implementation as a whole, only of its execution speed on some particular piece(s) of code.
Java code can be slower than C++ code--sometimes by a factor much larger than 2 or 3.
Java code can also be competitive with C++ code--but often requires substantially more memory to do so.
For a few, very specific, things Java can be faster than C++ that's written similarly.
That said, yes, on average code written in Java will run slower than (roughly) equivalent code written in C++. If your primary concern is with execution speed, Java has a number of disadvantages.
The main one is that it depends heavily on a JIT compiler for optimization--but since the user is waiting while the JIT compiler runs, most JIT compilers don't include the most expensive optimizations. Since a C++ compiler typically runs with only a developer waiting (or nobody waiting, in the case of server-based builds with CI systems and such) it's much more reasonable for the compiler to include every optimization in the book.
A second factor is closely related: C++ vendors see their customers as being extremely concerned with speed. Java vendors almost certainly see their customers as being more concerned with things like features and fast development than with achieving absolutely the highest possible execution speed. That's not to say they can or do neglect execution speed entirely, just that they don't emphasize it to nearly the same degree as C++ vendors.
Garbage collection can have an effect as well. Java (normally) uses a concurrent, copying collector. This works reasonably well across a wide variety of work loads, and most JVMs have some "tuning knobs" to help out when the default setting aren't optimum.
Nonetheless, testing seems to indicate that a JVM requires substantially more memory than equivalent C++ code to even hope to run at (approximately) the same speed. Especially when you're running in a memory-constrained situation, the overhead from garbage collection can increase substantially. This typically stems less from how often the garbage collector runs (in itself), than from the fact that when it runs, many objects are still "alive". A copying collector works by copying "live" (reachable) objects into a new location, so ideally you want nearly all objects to be "dead" (unreachable) before it runs. With less memory, it not only runs more often, but each iteration takes longer because fewer objects have aged enough to "die", and more objects remain reachable (and therefore need to be copied).
There's also a difference in the amount of work that's done at run time vs. compile time. C++ places a high emphasis on doing as much as possible at compile time. For example, all the cool template "stuff" happens entirely at compile time (at the expense of horribly long compile times in some cases). Despite similar syntax, much (most?) of Java's enforcement of types in its generics system happens at run-time. Java also includes (and many Java programs use) such things as reflection, which simply aren't present in C++.
Java also adds a number of convenience features such as auto-boxing that make it fairly easy to add quite a bit of overhead to seemingly simple operations in ways that aren't immediately apparent. C++ has some of these as well, but (it seems to me) they're both fewer in number, and their detrimental effects are typically somewhat less drastic (but my opinion on that may well be affected by the fact that I know C++ quite a bit better, so to me, similar problems may seem much more obvious in C++ than in Java).
Bottom line: it's difficult to point to a single, specific reason that Java programs are slower than C++ programs. Although it's true much more often than not, the reasons for its happening vary widely, and in many cases it seems to be more the "death of a thousand nicks" than being the result of a single factor.