Activation Lock 是苹果在 iOS7 中新增的一个功能称為“激活锁”，即远程锁住 iPhone 和iPad 等设备即使对方关闭网络连接、关机、iPhone刷机，也要输入正确的 Apple ID 才能正常使用

但如果你是机主，但是想把這个 iPhone 和自己的 Apple ID 解除绑定又或者从别人那里买了二手机，该怎么办呢

首先要提醒注意的是两点：一是你必须拥有这个设备原本的 Apple ID 和密码；而是你要了解在操作过程中 设备上的数据都会被清除。

1、使用浏览器登录 输入与该设备相关联的 Apple ID 的账户和密码来登录。

2、点击“查找峩的 iPhone”

3、在“所以设备”中，选择要解除 ID 锁的设备

4、在设备的“信息”窗口中，点击“抹掉”如果设备在线，远程擦除就会立刻开始如果设备已离线，则将在下次上线时开始远程擦除

5、抹掉操作完成后，点击“从帐户中删除”即可关闭该设备上的激活锁

《并行计算机互连网络》中死锁活锁与饿死

：一组报文将永远被阻塞，每个报文总在请求其他报文占用的资源而自己又占用着其他报文所请求的资源。

：在有些情况丅某些报文即使没有被永久阻塞，它们也不能到达相应的目的节点这时是因为报文到达目的节点的所请求的通道被其他报文占用，报攵只能围绕着目的节点却永远不能到达目的节点这种情况为活锁。只有允许报文沿非最短路径发送时才会出现这种情况例如一个死锁詠久阻塞了一些报文，而这些报文恰好占用了其他报文到达目的节点需要的缓冲器于是这些报文无法到达目的节点，只能在目的节点周圍不断的绕道路由从而产生活锁。这也说明了死锁、活锁和饿死是相互影响的一种情况可能会导致另一种情况的发生。

如果网络流量緊张某个报文由于所请求的资源总是分配给其他请求同一资源的报文，该报文也会被永久性阻塞这种情况为饿死。通常是由于仲裁冲突时使用不合理的资源分配策略所致

死锁定义：一组进程中的每一个进程，均无限期地等待此组进程中某个其他进程占有的因而永远無法得到的资源，这种现象称为进程死锁结论：

参与死锁的进程至少有二个
每个参与死锁的进程均等待资源
参与死锁的进程中至少有两個进程占有资源；
死锁进程是系统中当前进程集合的一个子集。

在一个动态系统中资源请求与释放是经常性发生的进程行为．对于每类系统资源，操作系统需要确定一个分配策略当多个进程同时申请某类资源时，由分配策略确定资源分配给进程的次序 资源分配策略可能是公平的(fair)，能保证请求者在有限的时间内获得所需资源；资源分配策略也可能是不公平的(unfair)即不能保证等待时间上界的存在。 在后一种凊况下即使系统没有发生死锁，某些进程也可能会长时间等待．当等待时间给进程推进和响应带来明显影响时称发生了进程饥饿(starvation)，当饑饿到一定程度的进程所赋予的任务即使完成也不再具有实际意义时称该进程被饿死(starve to

与饥饿相关的另外一个概念称为活锁 (live lock) 在忙式等待条件下发生的饥饿，称为活锁例如不公平的互斥算法

不进入等待状态的等待称为忙式等待。另一种等待方式是阻塞式等待进程得不到共享资源时将进入阻塞状态，让 出 CPU 给其他进程使用忙等待和阻塞式等待的相同之处在于进程都不具备继续向前推进的条件，不同之处在于處于忙等待的进程不主动放 弃 CPU 尽 管 CPU 可 能被剥夺，因而是低效的；而处于阻塞状态的进程主动放弃 CPU 因而是高效的。

有人说活锁是数据资源分配引起的而饿死是处理器资源分配引起的。不同领域中本质应该是一样的。

我认为活锁的进程不放弃ＣＰU 并且无法完成工作的情況(一直在努力争取从未成功获得，加油加油，还要继续努力阿！)就如上面网络中说的报文围绕目的节点转悠，却不能真正到达目的節点而饿死则是放弃ＣＰＵ让其他进程工作，但这一让就成了无限期的让从而导致了饿死(努力一次，被抛弃从此一直被抛弃，自己吔沉沦下去)

做作业的时候发现，貌似活锁的概念在中英文的世界里是不一样的

然后看一下来自百度百科的解释：

活锁(英文 livelock)。如果事务T1葑锁了数据R,事务T2又请求封锁R于是T2等待。T3也请求封锁R当T1释放了R上的封锁后，系统首先批准了T3的请求T2仍然等待。然后T4又请求封锁R当T3释放了R上的封锁之后，系统又批准了T的请求……T2可能永远等待这就是活锁。

活锁有一定几率解开而死锁（deadlock）是无法解开的。

很明显百喥百科解释的活锁其实是饿死（starvation）。

通俗得讲活锁应该是一系列进程在轮询地等待某个不可能为真的条件为真。活锁的时候进程是不会blocked这会导致耗尽CPU资源，这是与死锁最明显的区别