这时候，就要涉及到区块的卸载原理了。

区块的卸载有两种触发方式：

1.玩家远离区块那一刻

2.每45秒的检查

而不管是哪种触发方式，卸载的方法都相同：

1.游戏会将这些要卸载的区块都添加进一个表格，即哈希表。

2.游戏会按照哈希表的顺序来逐个卸载，然鹅这个顺序不一定是区块加载的顺序。

3.在每一刻的最后，游戏会进入区块卸载模式，但游戏每一次最多只能卸载100个区块，剩下的区块会等待下一次卸载。

这些险些被卸载的区块都还会正常运作，但游戏已经把它们贴在了卸载表上，相当于加上了一个死亡倒计时。

本小章还未完，请点击下一页继续阅读后面精彩内容！

这些区块还有救吗？有救，只需要在下一次卸载之前，漏斗能提前加载那些区块，就可以将那个区块从卸载表上扯下来，让区块继续运作。

那么，我们就可以选择哈希表靠后的区块，我们就有机会它一直被漏斗加载。

没错，但是你该怎么知道哪个区块在哈希表靠后的地方？

其实哈希表的排序并不是随机的，而是有规律的。哈希表并不是单纯的一个表格，它是由哈希键索引的各种桶组合在一起的。而每一个区块的哈希键，由这个区块的X和Z来决定。也就是说，每个区块的卸载顺序，由这个区块的X和Z来决定。（注：一个区块的XZ为这个区块的中心位置，即在F3调试界面区块坐标XZ都为8的地方。

那么该怎么计算？

我们以世界原点（0，0）举个例子。

首先，游戏会将世界原点的X和Z轴转换成2进制，然后组合在一起，变成一个长8字节的2进制数字。而每个字节由8个2进制数字组成，所以这个8字节的二进制数字，就长达64个位数。即：

0000000000000000000000000000000000000000000000000000000000000000

（实际上这就是典型的64位，即64个位数，这下子你应该知道了这个64和32位操作系统的区别了吧）

然后游戏就会把这串数字交给JAVA处理。JAVA首先会把这个数字分成两半，即：

00000000000000000000000000000000-00000000000000000000000000000000

（这其实有些像我们以前讲过的UUID）

接着JAVA会把这串分成两半的数字左边跟右边做一次异或运算（即上面和下面的数字相同，输出0，不同，输出1），也就是：

00000000000000000000000000000000

00000000000000000000000000000000

得出来的结果是32位数：

00000000000000000000000000000000

你以为这就完了吗？其实还没完，JAVA会再把这串数字分两半，再异或，即：

0000000000000000-0000000000000000（32位）

—异或—

0000000000000000（16位）

然后把这个16位的二进制数字转化成10进制，即：0。

这就代表着这个区块的卸载顺序为0。

现在我们换一个坐标，换（3，3）吧：

3-3（10进制）

—转2进制—

00000000000000000000000000000011-00000000000000000000000000000011

—异或—

0000000000000000-0000000000000000

—异或—

0000000000000000

—转10进制—

0

3，3坐标竟然还是0。

所以我们可以得出一个结论：由于对角线的坐标X和Z的数字相同，导致异或后肯定为0，所以对角线的坐标在哈希表里的排序肯定为0。