针对项目中同步队列死锁的解决方案

好久没有写blog了，一来没时间，二来嘛，懒！（这是主要原因）。今天遇到一个很有意思的问题，目前已经解决了，供有相同困境的同仁参考啊！在维护公司的一个有着三年历史的项目的时候，发现了一个很诡异的现象，每次调用开台、检查客位、档案更新等其他接口的时候，webclient客户端均能正常反应，网络信号较差的时候，设置的网络超时机制也可以恰到好处的起到他的作用。唯独提交菜品调用加单接口的时候，会出现服务器端已经显示加单成功，并且开始调用打印机开始打印账单了，而我们可怜的iPad上面均要死不活的出现着一个警告框：“正在提交中，请稍后。。。”

更糟糕的是，为了防止我在调用提交的时候，客户会操作UI，因此我将调用加单接口放进了主线程中，so,程序和死机了没什么两样，一直会保持这个界面，而食客什么也做不了。。悲催啊。。

   刚开始，我以为是警告框的问题在作祟，因此我再次设置了一个计时器，当警告框每节操的停留太久的时候，我会调用方法强制把他请走！但是问题又来了！没了这货，客户可以随意操作UI了，但是这次网络请求的生命周期并没有结束，于是更悲剧的结果诞生了：程序频繁crash掉！ 

   我是这么处理收到服务器反馈的数据的： 

-(void)operation:(TCSLServiceBindingOperation *)operation completedWithResponse:(TCSLServiceBindingResponse *)response{    if(response.error != NULL)    {        [self performSelectorOnMainThread:@selector(reTry) withObject:nil waitUntilDone:YES];    }else    {        [self dismissAlertView];        //[self performSelectorOnMainThread:@selector(dismissAlertView) withObject:nil waitUntilDone:YES];                for (id mine in response.bodyParts)        {            if([mine isKindOfClass:[TCSLService_TCSLService___RequestResponse class]])            {                TCSLService_TCSLService___RequestResponse *res =(TCSLService_TCSLService___RequestResponse *)mine;                [iBus ResponseXML:res.AResponseXML];            }        }                if ([self.delegate respondsToSelector:@selector(netWorkTransOnSuccess)]) {            [self.delegate netWorkTransOnSuccess];        }    }}

    回调方法：

// 网络传输成功返回委托实现- (void) netWorkTransOnSuccess{    switch (Bus_Type) {        case BUS_CODE_CHECKUSER:        {            if (self.business_Request.Sucess) {                Bus_Type=BUS_CODE_CHECKTABLE;                [self.business_Request CheckOpenTable:edtTableCode.text];            }else{                UIAlertView *alertView = [[UIAlertView alloc]initWithTitle:@"提示" message:self.business_Request.Msg delegate:self cancelButtonTitle:@"确定" otherButtonTitles:nil];                [alertView setTag:-1];                [alertView show];                [alertView release];                        }                        break;        }        case BUS_CODE_CHECKTABLE:        {            if (self.business_Request.Sucess) {                //如果查询客位状态成功                APDocument *doc = [APDocument documentWithXMLString:self.business_Request.XML];                                APElement *root = [doc rootElement];                int tableStatus = [[root valueForAttributeNamed:@"PointStatus"] intValue];                NSString *upDateTime = [root valueForAttributeNamed:@"LastTime"];                [self.tcSystem w_UpdateTime:upDateTime]; //记录上次更新的时间                                if (tableStatus==3) { //如果是占用状态                    //执行加单操作                    if (itemOrder.bLock) {                        NSString *str=[NSString stringWithFormat:@"当前菜单 %@ 已经提交过，确定要提交该菜单吗？\r\n如果在上次提交时服务器端已经完成加单操作，本次提交以及菜品的更改将不会生效。",itemOrder.OrderNO];                        UIAlertView *alterView = [[UIAlertView alloc]initWithTitle:@"警告" message:str delegate:self cancelButtonTitle:@"提交" otherButtonTitles: nil];                        alterView.tag = 2;                        [alterView show];                        [alterView release];                    }else{                        [itemOrder lock];                        [self performSelector:@selector(submitOrder) withObject:nil afterDelay:2.0f];//                        Bus_Type=BUS_CODE_SUBMIT;//                         [self.business_Request AddOrder:[xml description]];                    }                }                else{ //如果不是占用状态,则不能进行加单操作                    NSString * msg = [self getTableState:tableStatus];                    UIAlertView * alertView = [[UIAlertView alloc] initWithTitle:@"抱歉" message:msg delegate:nil cancelButtonTitle:@"我知道了" otherButtonTitles:nil];                    [alertView show];                    [alertView release];                    return;                }                        }else{ //如果接收程序没有回应                NSString *msg = self.business_Request.Msg;                //NSString * msg = @"查询客位状态失败!是否再次尝试?";                UIAlertView * alertView = [[UIAlertView alloc] initWithTitle:@"抱歉" message:msg delegate:self cancelButtonTitle:@"重试" otherButtonTitles:@"取消",nil];                 alertView.tag=TAG_CHECK_TABLE;                [alertView show];                [alertView release];                return;            }            break;        }        case BUS_CODE_SUBMIT:        {            //菜品提交返回成功            [alertMsgView setMessage:self.business_Request.Msg];            if (self.business_Request.Sucess) {                [alertMsgView setTag:1];                //保存本次加单的时间                [self.tcSystem w_SubmitTime:[self getCurrentTime]];                            } else {                [alertMsgView setTag:-1];            }            [alertMsgView show];            break;        }        default:            break;    }}

    问题在哪呢？经过我多次调试，发现了一个很有趣的现象，这个现象特别隐秘，因此很不容易发现。因为调用加单接口的时候，需要首先调用客位状态的接口，当收到客位状态接口返回值为1（占用）的时候，就会立刻发起加单的网络请求。但是此时，调用客位状态接口的request释放了吗？他的生命周期走到头了吗？答案是不一定的，有时候会走完，有时候会走不完，并且走不完的概率大约为1%。测试的GGMM也辛苦了啊，点击100次可能有那么一次出现上面宕机的问题，相当考验人的耐心哦！

  OK，既然发现了问题，我想了三种处理方式，目前只是采用了其中的一种，现在经过回归测试，没有再现这个宕机的问题，谢天谢地啊！方式1：修改服务器端的加单接口，将检查客位状态的接口与加单接口整合，这个方法很麻烦，需要服务器端的人配合，但是一劳永逸； 方式二：（我目前采用的） 采取延时操作，当收到客位状态的时候，不是立马发送加单请求，而是停留2秒的时间再发送，经过我的研究，2秒钟足够调用十多次检查客位状态的接口了！因此能够解决我的困境； 方式三：加状态值进行判断，如果检查客位状态的接口回调方法结束之后，设置一个状态为YES，当状态为YES的时候才发起网络请求。此方法有缺陷，因为虽然回调方法走完了，但是request有没有Over我也不知道。但是作为一个备用思路未尝不是一个好的解决方案。

     好了。就此停笔。