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

好久没有写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(netWork
b1ba
TransOnSuccess)]) {
[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我也不知道。但是作为一个备用思路未尝不是一个好的解决方案。

     好了。就此停笔。