a cache hit
You reach for a pen and — lucky you — it is already on your desk. No trip to the drawer, no rummaging; you have it instantly. A cache hit is exactly that moment of good fortune for a memory access: the data the CPU asked for is already present in the cache, so it can be delivered quickly without going to the slower memory below.
Mechanically, on each access the cache uses part of the address to look in the right place and compares the stored tags against the rest of the address. If a stored line's tag matches and that line is valid, it is a hit: the requested byte is read straight out of the fast cache, taking only the hit time (often a single cycle or a few cycles for L1). The fraction of accesses that hit is the hit rate, and its complement, the miss rate, is one minus the hit rate. Driving the hit rate up is the central goal of cache design and of writing locality-friendly code.
Hits are the whole reason the hierarchy works: because locality makes the vast majority of accesses hits, the average memory access time stays close to the fast hit time even though every miss is expensive. A useful honesty: a 'high' hit rate is not as comforting as it sounds, because misses are so much costlier than hits. Going from a 97 percent to a 99 percent hit rate may sound like a small improvement, yet it can roughly halve the miss traffic and noticeably speed up a program — the few percent of misses often dominate the total time.
If 95 of every 100 accesses hit (hit time 1 cycle) and 5 miss (miss penalty 100 cycles), the misses alone cost 500 cycles versus 95 for all the hits combined. Pushing hits to 98 of 100 cuts miss cost from 500 to 200 cycles — the rare misses dominate.
The lucky case: the data is already in the cache, served at the fast hit time.
A high hit rate can hide a slow program. Because each miss is tens to hundreds of times costlier than a hit, even a 1-2 percent miss rate can dominate total memory time. Judge by AMAT (which weights misses by their penalty), not by hit rate alone.