下次自动登录
现在的位置:
& 综合 & 正文
什么是死锁及死锁的必要条件和解决方法【转】
进程死锁及解决办法
16:48:58 阅读767 评论 大中小
&&&&推荐文章:
【上篇】【下篇】彻底搞懂OC中GCD导致死锁的原因和解决方案
时间： 00:52:28
&&&& 阅读：4563
&&&& 评论：
&&&& 收藏：0
标签：&&&&&&&&&&&&&&&GCD提供了功能强大的任务和队列控制功能，相比于NSOperationQueue更加底层，因此如果不注意也会导致死锁。
所谓死锁，通常指有两个线程A和B都卡住了，并等待对方完成某些操作。A不能完成是因为它在等待B完成。但B也不能完成，因为它在等待A完成。于是大家都完不成，就导致了死锁（DeadLock）。
有一定GCD使用经验的新手通常认为，死锁是很高端的操作系统层面的问题，离我很远，一般不会遇上。其实这种想法是非常错误的，因为只要简单三行代码（如果愿意，甚至写在一行就可以）就可以人为创造出死锁的情况。
int main(int argc, const char * argv[]) {
@autoreleasepool {
dispatch_sync(dispatch_get_main_queue(), ^(void){
NSLog(@"这里死锁了");
比如这个最简单的OC命令行程序就会导致死锁，运行后不会看到任何结果。
在解释为什么会死锁之前，首先明确一下“同步&异步”“串行&并发”这两组基本概念：
同步执行：比如这里的dispatch_sync，这个函数会把一个block加入到指定的队列中，而且会一直等到执行完blcok，这个函数才返回。因此在block执行完之前，调用dispatch_sync方法的线程是阻塞的。
与之对应的就有“异步执行”的概念：
异步执行：一般使用dispatch_async，这个函数也会把一个block加入到指定的队列中，但是和同步执行不同的是，这个函数把block加入队列后不等block的执行就立刻返回了。
接下来看一看另一组相对的概念：“串行&并发”
串行队列：比如这里的dispatch_get_main_queue。这个队列中所有任务，一定按照先来后到的顺序执行。不仅如此，还可以保证在执行某个任务时，在它前面进入队列的所有任务肯定执行完了。对于每一个不同的串行队列，系统会为这个队列建立唯一的线程来执行代码。
与之相对的是并发队列：
并发队列：比如使用dispatch_get_global_queue。这个队列中的任务也是按照先来后到的顺序开始执行，注意是开始，但是它们的执行结束时间是不确定的，取决于每个任务的耗时。对于n个并发队列，GCD不会创建对应的n个线程而是进行适当的优化
我们把整个dispatch_sync看作是一个任务，比如说是非常关键、需要高度集中注意力的运钞过程。这个过程非常重要，一旦开始执行就必须一气呵成，任何事情都不能干扰这个过程（阻塞线程）。
现在主线程开始执行这个运钞任务，任务执行到一半时，突然运钞员说我好累啊，辛苦了好久了，我现在需要休息（向主线程添加了block）。运钞员天真的认为，我知道运钞这个事很重要，本来应该等到运钞结束后再休息（这样是串行）。但是在这之前，我的身体条件不允许工作。
但是之前已经说了，运钞这件事很重要，它一旦开始就不能结束（阻塞线程）。怎么能允许有人中途休息呢，因此要休息可以（block是可以执行的），先把钞票运到安全地方再休息。
对应到代码里面来，当我们想要同步执行这个block的时候，其实是告诉主线程，你把事情处理完了，就过来处理我这个blcok，在此之前我一直等你。而主线程呢，刚处理dispatch_sync函数到一半呢，这个函数还没返回，哪里有空去执行block。因此这段代码运行后，并非卡在block中无法返回，而是根本无法执行到这个block。
好了，总结一下，到底什么是死锁。首先，虽然刚刚我们提到了队列和线程，以及它们之间的对应关系，但是死锁一定是针对线程而言的，队列只是GCD给出的抽象数据结构。所谓的死锁，一定是发生在一个或多个线程之间的。那么死锁和线程阻塞的关系呢，可以这么理解，双向的阻塞导致了死锁。因为阻塞是线程中经常发生的事情，最多就是主线程的阻塞影响了用户体验。而一旦出现了双向的阻塞，就导致了死锁。我们可以看到，主线程是串行的，在执行某一个任务的时候线程被阻塞了，而这个任务（dispatch_sync）在执行时，又要求阻塞主线程，从而导致了互相的阻塞，也就是死锁。
接下来我们思考一下，什么情况下会导致死锁。这个问题可能一下子难以得出准确的回答，为了解决这个问题，我打算使用排除法。即先看看什么情况下不会发生死锁。比如说，异步执行block肯定不会发生死锁。比如刚刚的代码改成这样：
dispatch_async(dispatch_get_global_queue(0,0), ^(void){
NSLog(@"这就不死锁了");
甚至可以总结出来：异步执行一定不会导致死锁。因为回顾一下之前导致的死锁的原因，很重要的一点是主线程在执行dispatch_sync，这是个同步方法，block执行完之前都不会返回。而既然是异步的执行，那么是立刻返回的，因此不会阻塞主线程。双向的阻塞不成立了，只是主线程处理blcok时阻塞，但这不会引起死锁。
根据之前我们的分析和总结，GCD中我们需要关心的就是同步还是异步执行，以及把block添加到哪个队列中（串行还是并发）。
所以接下来就只需要重点思考一下，在同步执行时，什么时候会导致死锁。可以再得出一个结论，向并发队列中添加block不会导致死锁。再次回顾一下之前导致的死锁的原因，由于在串行队列中添加了block，block一直等到前面的任务处理完才会执行，从而导致了死锁。现在即使是同步的向并发队列中添加block，GCD会自动为我们管理线程，主线程目前阻塞着（处理这个同步方法），那就新建一个新的线程，但无论如何这个被添加block迟早都会被执行。而所有添加的block被执行完后，同步方法也就返回了。因此不会导致死锁。
最后再来讨论一下用同步方法向串行队列添加block的情况，这种情况下会不会造成死锁呢，答案是不一定。事实上，导致死锁的原因一定是：
在某一个串行队列中，同步的向这个队列添加block。
比如文章开头的例子就属于这种情况。如果同步的向另外一个串行队列添加方法，并不一定导致死锁。比如：
dispatch_queue_t queue = dispatch_queue_create("serial", nil);
dispatch_sync(queue, ^(void){
NSLog(@"这个也不会死锁");
分析一下代码，向名为serial的串行队列添加任务后，GCD自动创建了一个新的线程，在这个线程中执行block方法。在这个过程中，主线程和新的线程都是阻塞的，但是并不会导致死锁。
为什么说向另一个串行队列添加任务不一定导致死锁呢，因为队列是可以嵌套的，比如在A队列（串行）添加一个任务a，在a这个任务中向B队列（串行）添加任务b，在b这个任务中又向A队列添加任务，这就间接满足了“在某一个串行队列中，同步的向这个队列添加block”。但是我们好像每一次都没有直接向相同的队列中添加block。
所以判断是否发生死锁的最好方法就是看有没有在串行队列（当然也包括主队列）中向这个队列添加任务。又因为我们知道每个串行队列对应一个线程，所以只要不在某个线程中调用会阻塞这个线程的方法即可。
事实上，我们使用同步的方法编程，往往是要求保证任务之间的执行顺序是完全确定的。且不说GCD提供了很多强大的功能来满足这个需求，向串行队列中同步的添加任务本身就是不合理的，毕竟队列已经是串行的了，直接异步添加就可以了啊。所以，解决文章开头那个死锁例子的最简单的方法就是在合适的位置添加一个字母a。
版权声明：本文为博主原创文章，未经博主允许不得转载。
标签：&&&&&&&&&&&&&&&
&&国之画&&&& &&&&chrome插件
版权所有 京ICP备号-2
迷上了代码！1491人阅读
数据库 - 锁（1）
1.死锁：如果一组进程中的每一个进程都在等待仅由该组进程中的其它进程才能引发的事件，那么该组进程是死锁的。
2.产生死锁的原因：
（1）竞争不可抢占性资源。
（2）竞争可消耗资源。
当系统中供多个进程共享的资源如打印机，公用队列等，其数目不足以满足诸进程的需要时，会引起诸进程对资源的竞争而产生死锁。
（3）进程推进顺序不当。
进程在运行过程中，请求和释放资源的顺序不当，也同样会导致产生进程死锁。
如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。
一个线程也可引起死锁。
3.产生死锁的四个必要条件：
（1） 互斥条件：一个资源每次只能被一个进程使用。
（2） 请求和保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
（3） 不可抢占条件:进程已获得的资源，在末使用完之前，不能强行剥夺，只能在进程使用完时由自己释放。
（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。因此可以写下如下的预防死锁的方法。
4.避免死锁的方法：
（1）破坏“互斥”条件:就是在系统里取消互斥。若资源不被一个进程独占使用，那么死锁是肯定不会发生的。但一般“互斥”条件是无法破坏的。因此，在死锁预防里主要是破坏其他三个必要条件，而不去涉及破坏“互斥”条件。
（2）破坏“请求和保持”条件:在系统中不允许进程在已获得某种资源的情况下，申请其他资源。即要想出一个办法，阻止进程在持有资源的同时申请其他资源。
方法一：所有进程在运行之前，必须一次性地申请在整个运行过程中所需的全部资源。这样，该进程在整个运行期间，便不会再提出资源请求，从而破坏了“请求”条件。系统在分配资源时，只要有一种资源不能满足进程的要求，即使其它所需的各资源都空闲也不分配给该进程，而让该进程等待。由于该进程在等待期间未占有任何资源，于是破坏了“保持”条件。
该方法优点：简单、易行且安全。
缺点：a.资源被严重浪费，严重恶化了资源的利用率。
b.使进程经常会发生饥饿现象。
方法二：要求每个进程提出新的资源申请前，释放它所占有的资源。这样，一个进程在需要资源S时，须先把它先前占有的资源R释放掉，然后才能提出对S的申请，即使它可能很快又要用到资源R。
（3）破坏“不可抢占”条件：允许对资源实行抢夺。
方法一：如果占有某些资源的一个进程进行进一步资源请求被拒绝，则该进程必须释放它最初占有的资源，如果有必要，可再次请求这些资源和另外的资源。
方法二：如果一个进程请求当前被另一个进程占有的一个资源，则操作系统可以抢占另一个进程，要求它释放资源。只有在任意两个进程的优先级都不相同的条件下，该方法才能预防死锁。
（4）破坏“循环等待”条件：将系统中的所有资源统一编号，进程可在任何时刻提出资源申请，但所有申请必须按照资源的编号顺序（升序）提出。这样做就能保证系统不出现死锁。
利用银行家算法避免死锁：
银行家算法:
设进程i提出请求Request[j]，则银行家算法按如下规则进行判断。
(1) 如果Request[j]≤Need[i,j]，则转向（2），否则认为出错，因为它所需要的资源数已超过它所宣布的最大值。
(2) 如果Request[j]≤Available[j]，则转向（3）；否则表示尚无足够资源，Pi需等待。
(3) 假设进程i的申请已获批准，于是修改系统状态：
Available[j]=Available[j]-Request[i]
Allocation[i,j]=Allocation[i,j]+Request[j]
Need[i,j]=Need[i,j]-Request[j]
(4)系统执行安全性检查，如安全，则分配成立；否则试探险性分配作废，系统恢复原状，进程等待。
安全性算法：
(1) 设置两个工作向量Work=Available；Finish[i]=False
(2) 从进程集合中找到一个满足下述条件的进程，
Finish [i]=F
Need[i,j]≤Work[j];
如找到，执行(3)；否则，执行(4)
(3) 设进程获得资源，可顺利执行，直至完成，从而释放资源。
Work[j]=Work[j]+Allocation[i,j];
Finish[i]=T
Go to step 2;
(4) 如所有的进程Finish[i]=true，则表示安全；否则系统不安全。
5.死锁的解除：
一旦检测出死锁，就应立即釆取相应的措施，以解除死锁。死锁解除的主要两种方法：
1) 抢占资源。从一个或多个进程中抢占足够数量的资源，分配给死锁进程，以解除死锁状态。
2) 终止（或撤销）进程。终止（或撤销）系统中的一个或多个死锁进程，直至打破循环环路，使系统从死锁状态解脱出来。
一般情况下,如果同一个线程先后两次调用lock,在第二次调用时,由于锁已经被占用,该线程会挂起等待别的线程释放锁,然而锁正是被自己占用着的,该线程又被挂起而没有机会释放锁,因此就永远处于挂起等待状态了,这叫做死锁(Deadlock)。另?一种典型的死锁情形是这样:线程A获得了锁1,线程B获得了锁2,这时线程A调?用lock试图获得锁2,结果是需要挂起等待线程B释放锁2,而这时线程B也调?用lock试图获得锁1,结果是需要挂起等待线程A释放锁1,于是线程A和B都永远处于挂起状态了。
写程序时应该尽量避免同时获得多个锁,如果一定有必要这么做,则有一个原则:如果所有线程在需要多个锁时都按相同的先后顺序(常见的是按Mutex变量的地址顺序)获得锁,则不会出现死锁。比如一个程序中用到锁1、锁2、锁3,它们所对应的Mutex变量的地址是锁1&锁2&锁3,那么所有线程在需要同时获得2个或3个锁时都应该按锁1、锁2、锁3的顺序获得。如果要为所有的锁确定一个先后顺序比较困难,则应pthread_mutex_trylock调用代替pthread_mutex_lock 调用,以免死锁。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：10937次
排名：千里之外
原创：30篇
转载：23篇五个案例让你明白GCD死锁 - IOS - 伯乐在线
& 五个案例让你明白GCD死锁
死锁一直都是在使用多线程时，需要注意的一个问题。以前对同步、异步，串行、并行只有一个模糊的概念，想想也是时候整理一下了。再看看之前的博客，已经很久没有干货了【说得好像之前有干货一样】，所以，这篇博客，我尽最大努力，也借鉴了很多其他博客中的例子，来讲解GCD死锁问题。
环境信息：
Mac OS X 10.10.5
串行与并行
在使用GCD的时候，我们会把需要处理的任务放到Block中，然后将任务追加到相应的队列里面，这个队列，叫做Dispatch Queue。然而，存在于两种Dispatch Queue，一种是要等待上一个执行完，再执行下一个的Serial Dispatch Queue，这叫做串行队列；另一种，则是不需要上一个执行完，就能执行下一个的Concurrent Dispatch Queue，叫做并行队列。这两种，均遵循FIFO原则。
举一个简单的例子，在三个任务中输出1、2、3，串行队列输出是有序的1、2、3，但是并行队列的先后顺序就不一定了。
那么，并行队列又是怎么在执行呢？
虽然可以同时多个任务的处理，但是并行队列的处理量，还是要根据当前系统状态来。如果当前系统状态最多处理2个任务，那么1、2会排在前面，3什么时候操作，就看1或者2谁先完成，然后3接在后面。
串行和并行就简单说到这里，关于它们的技术点其实还有很多，可以自行了解。
同步与异步
串行与并行针对的是队列，而同步与异步，针对的则是线程。最大的区别在于，同步线程要阻塞当前线程，必须要等待同步线程中的任务执行完，返回以后，才能继续执行下一任务；而异步线程则是不用等待。
仅凭这几句话还是很难理解，所以之后准备了很多案例，可以边分析边理解。
GCD API很多，这里仅介绍本文用到的。
1. 系统标准提供的两个队列
Objective-C
// 全局队列，也是一个并行队列
dispatch_get_global_queue
// 主队列，在主线程中运行，因为主线程只有一个，所以这是一个串行队列
dispatch_get_main_queue
// 全局队列，也是一个并行队列dispatch_get_global_queue // 主队列，在主线程中运行，因为主线程只有一个，所以这是一个串行队列dispatch_get_main_queue &
2. 除此之外，还可以自己生成队列
Objective-C
// 从DISPATCH_QUEUE_SERIAL看出，这是串行队列
dispatch_queue_create("com.demo.serialQueue", DISPATCH_QUEUE_SERIAL)
// 同理，这是一个并行队列
dispatch_queue_create("com.demo.concurrentQueue", DISPATCH_QUEUE_CONCURRENT)
// 从DISPATCH_QUEUE_SERIAL看出，这是串行队列dispatch_queue_create("com.demo.serialQueue", DISPATCH_QUEUE_SERIAL) // 同理，这是一个并行队列dispatch_queue_create("com.demo.concurrentQueue", DISPATCH_QUEUE_CONCURRENT) &
接下来是同步与异步线程的创建：
Objective-C
dispatch_sync(..., ^(block)) // 同步线程
dispatch_async(..., ^(block)) // 异步线程
dispatch_sync(..., ^(block)) // 同步线程dispatch_async(..., ^(block)) // 异步线程&
案例与分析
假设你已经基本了解了上面提到的知识，接下来进入案例讲解阶段。
Objective-C
NSLog(@"1"); // 任务1
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@"2"); // 任务2
NSLog(@"3"); // 任务3
NSLog(@"1"); // 任务1dispatch_sync(dispatch_get_main_queue(), ^{&&&&NSLog(@"2"); // 任务2});NSLog(@"3"); // 任务3&
结果，控制台输出：
Objective-C
dispatch_sync表示是一个同步线程；
dispatch_get_main_queue表示运行在主线程中的主队列；
任务2是同步线程的任务。
首先执行任务1，这是肯定没问题的，只是接下来，程序遇到了同步线程，那么它会进入等待，等待任务2执行完，然后执行任务3。但这是队列，有任务来，当然会将任务加到队尾，然后遵循FIFO原则执行任务。那么，现在任务2就会被加到最后，任务3排在了任务2前面，问题来了：
任务3要等任务2执行完才能执行，任务2由排在任务3后面，意味着任务2要在任务3执行完才能执行，所以他们进入了互相等待的局面。【既然这样，那干脆就卡在这里吧】这就是死锁。
Objective-C
NSLog(@"1"); // 任务1
dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
NSLog(@"2"); // 任务2
NSLog(@"3"); // 任务3
NSLog(@"1"); // 任务1dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{&&&&NSLog(@"2"); // 任务2});NSLog(@"3"); // 任务3&
结果，控制台输出：
Objective-C
首先执行任务1，接下来会遇到一个同步线程，程序会进入等待。等待任务2执行完成以后，才能继续执行任务3。从dispatch_get_global_queue可以看出，任务2被加入到了全局的并行队列中，当并行队列执行完任务2以后，返回到主队列，继续执行任务3。
Objective-C
dispatch_queue_t queue = dispatch_queue_create("com.demo.serialQueue", DISPATCH_QUEUE_SERIAL);
NSLog(@"1"); // 任务1
dispatch_async(queue, ^{
NSLog(@"2"); // 任务2
dispatch_sync(queue, ^{
NSLog(@"3"); // 任务3
NSLog(@"4"); // 任务4
NSLog(@"5"); // 任务5
1234567891011
dispatch_queue_t queue = dispatch_queue_create("com.demo.serialQueue", DISPATCH_QUEUE_SERIAL);NSLog(@"1"); // 任务1dispatch_async(queue, ^{&&&&NSLog(@"2"); // 任务2&&&&dispatch_sync(queue, ^{&&&&&&&&&&NSLog(@"3"); // 任务3&&&&});&&&&NSLog(@"4"); // 任务4});NSLog(@"5"); // 任务5&
结果，控制台输出：
Objective-C
// 5和2的顺序不一定
152// 5和2的顺序不一定&
这个案例没有使用系统提供的串行或并行队列，而是自己通过dispatch_queue_create函数创建了一个DISPATCH_QUEUE_SERIAL的串行队列。
执行任务1；
遇到异步线程，将【任务2、同步线程、任务4】加入串行队列中。因为是异步线程，所以在主线程中的任务5不必等待异步线程中的所有任务完成；
因为任务5不必等待，所以2和5的输出顺序不能确定；
任务2执行完以后，遇到同步线程，这时，将任务3加入串行队列；
又因为任务4比任务3早加入串行队列，所以，任务3要等待任务4完成以后，才能执行。但是任务3所在的同步线程会阻塞，所以任务4必须等任务3执行完以后再执行。这就又陷入了无限的等待中，造成死锁。
Objective-C
NSLog(@"1"); // 任务1
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"2"); // 任务2
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@"3"); // 任务3
NSLog(@"4"); // 任务4
NSLog(@"5"); // 任务5
12345678910
NSLog(@"1"); // 任务1dispatch_async(dispatch_get_global_queue(0, 0), ^{&&&&NSLog(@"2"); // 任务2&&&&dispatch_sync(dispatch_get_main_queue(), ^{&&&&&&&&NSLog(@"3"); // 任务3&&&&});&&&&NSLog(@"4"); // 任务4});NSLog(@"5"); // 任务5&
结果，控制台输出：
Objective-C
// 5和2的顺序不一定
12534// 5和2的顺序不一定&
首先，将【任务1、异步线程、任务5】加入Main Queue中，异步线程中的任务是：【任务2、同步线程、任务4】。
所以，先执行任务1，然后将异步线程中的任务加入到Global Queue中，因为异步线程，所以任务5不用等待，结果就是2和5的输出顺序不一定。
然后再看异步线程中的任务执行顺序。任务2执行完以后，遇到同步线程。将同步线程中的任务加入到Main Queue中，这时加入的任务3在任务5的后面。
当任务3执行完以后，没有了阻塞，程序继续执行任务4。
从以上的分析来看，得到的几个结果：1最先执行；2和5顺序不一定；4一定在3后面。
Objective-C
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"1"); // 任务1
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@"2"); // 任务2
NSLog(@"3"); // 任务3
NSLog(@"4"); // 任务4
while (1) {
NSLog(@"5"); // 任务5
123456789101112
dispatch_async(dispatch_get_global_queue(0, 0), ^{&&&&NSLog(@"1"); // 任务1&&&&dispatch_sync(dispatch_get_main_queue(), ^{&&&&&&&&NSLog(@"2"); // 任务2&&&&});&&&&NSLog(@"3"); // 任务3});NSLog(@"4"); // 任务4while (1) {}NSLog(@"5"); // 任务5&
Objective-C
结果，控制台输出：
结果，控制台输出：
Objective-C
// 1和4的顺序不一定
14// 1和4的顺序不一定&
和上面几个案例的分析类似，先来看看都有哪些任务加入了Main Queue：【异步线程、任务4、死循环、任务5】。
在加入到Global Queue异步线程中的任务有：【任务1、同步线程、任务3】。
第一个就是异步线程，任务4不用等待，所以结果任务1和任务4顺序不一定。
任务4完成后，程序进入死循环，Main Queue阻塞。但是加入到Global Queue的异步线程不受影响，继续执行任务1后面的同步线程。
同步线程中，将任务2加入到了主线程，并且，任务3等待任务2完成以后才能执行。这时的主线程，已经被死循环阻塞了。所以任务2无法执行，当然任务3也无法执行，在死循环后的任务5也不会执行。
最终，只能得到1和4顺序不定的结果。
可能感兴趣的话题
案例一，队列里任务三为什么会在任务二上边呢
关于iOS频道
iOS频道分享iOS和Swift开发，应用设计和推广，iOS相关的行业动态。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2017 伯乐在线百度拇指医生
&&&普通咨询
您的网络环境存在异常，
请输入验证码
验证码输入错误，请重新输入}