首先为什么要做这样的判断呢？

    当你要strcpy活着strcmp或者hash一个字符串的时候，传统的方法是每个byte进行比较。以strcpy为例，当一个字符串比较长，我们用32(或者64位)的字长进行copy的话，一次拷贝会拷贝4个byte，能节省很多时间(忽略内存对齐等情况)。

    但是，使用32位的字长进行拷贝一个难点就是判断字符串的结尾，因为字符串长度不一定是4的整数倍，每次从内存中取4个byte，我们需要判断这4个byte中是否有某个byte是0，从而判断字符串是否结束。

    最传统的做法就是对每个字节进行一次判断，或者将所有字节乘起来，看结果是否是0：http://www.spongeliu.com/

unsigned char * p = (unsigned char *) & v;  
bool hasNoZeroByte = *p && *(p + 1) && *(p + 2) && *(p + 3);

    上面的代码需要12步操作，并且需要若干乘指令，效率不高。

    一种传统有效的方法是通过对每个byte进行一次掩码的操作来判断是否存在0：

bool hasNoZeroByte = ((v & 0xff) && (v & 0xff00) && (v & 0xff0000) && (v & 0xff000000));

    上面的操作相当于取出每一个byte，并进行与操作，最终判断是否是0，这样做需要进行7次操作。

    那么，是否有更快的方法呢？ 看下面的表达式：

unsigned int v; // 32-bit word to check if any 8-bit byte in it is 0
bool hasZeroByte = ~((((v & 0x7F7F7F7F) + 0x7F7F7F7F) | v) | 0x7F7F7F7F);

    这种方法进行了5次操作来完成整个工作！具体是怎么做到的，让我们仔细来看：

    首先，将v同 0x7f7f7f7f 进行&操作，目的是将v中每个byte的最高位清零；

    然后，再加上 0x7f7f7f7f 的目的是让每个byte的低7位溢出，这个时候只要每个byte的低7位不全是0，那么就会溢出；

    随后，我们再将得到的数同原先的v进行一个“按位或”的操作，这样每个byte的最高位都会被置为1，除非这个byte初始为0(若初始为0，则第二步的时候不会溢出，第三步的时候0|0还是0)；

    再然后，我们再讲得到的数同 0x7f7f7f7f “按位或”，则如果初始的数不包含0byte，我们就会得到0xffffffff，否则我们得不到这个数；

    最后，进行一个“按位否”操作，就会得到一个0或者非0。

    我们用两个例子来更直观的说明，先举一个不包含0byte的32位数，以 0x5FF23D6E 为例：

0x5FF23D6E & 0x7F7F7F7F = 0x5f723d6e;  //每个byte的高位全清0
0x5f723d6e + 0x7F7F7F7F = 0xdef1bced; //对每个byte的低7位进行溢出，只有当一个byte是0或者是“10000000”的时候不会溢出
0xdef1bced | 0x5FF23D6E = 0xdff3bdef; //或上原来的数，这是除非一个byte初始是0，否则最高位都会是1
0xdff3bdef | 0x7F7F7F7F = 0xffffffff; //将所有bit置为1
~ 0xffffffff = 0; //得到结果

    再使用一个包含0byte的32位数为例，以 0x5FF2006E 为例：

0x5FF2006E & 0x7F7F7F7F = 0x5f72006e;  //每个byte的高位全清0
0x5f72006e + 0x7F7F7F7F = 0xdef17fed; //对每个byte的低7位进行溢出，这个时候因为第三个byte是0，所以这个byte的最高位不是1
0xdef17fed | 0x5FF2006E = 0xdff37fef; //或上原来的数，第三个byte最高位不是1
0xdff37fef | 0x7F7F7F7F = 0xffff7fff; //第三个byte最高位不是1，其他所有位都是1
~ 0xffff7fff = 0x8000； //得到结果

    这种方法在一些字符串操作的性能优化，尤其是当大量字符串需要被哈希、拷贝时还是比较有效的。

    参考资料：http://graphics.stanford.edu/~seander/bithacks.html#ZeroInWord

建议继续学习：

1. java中byte转换int时为何与0xff进行与运算    (阅读：2910)
2. java中byte转换int时为何与0xff进行与运算    (阅读：2122)