Linux下套接字详解（七）----线程池accept处理高并发connect 前言 客户端模拟高并发 服务器处理大并发 代码

服务器在调用<code>listen</code>和<code>accept</code>后，就会阻塞在<code>accept</code>函数上，<code>accpet</code>函数返回后循环调用<code>accept</code>函数等待客户的<code>tcp</code>连接。

我们知道服务器段<code>listen</code>套接字能处理的连接数与监听队列的大小有关，如果这时候又大量的用户并发发起<code>connec</code>连接，那么在<code>listen</code>有队列上限(最大可接受tcp的连接数)的情况下，有多少个<code>connect</code>会成功了。

试验证明，当连接数远远高于<code>listen</code>的可连接数上限时，客户端的大部分<code>tcp</code>请求会被抛弃，只有当<code>listen</code>监听队列空闲或者放弃某个连接时，才可以接收新的连接

那么我们当并发的连接数较大时，服务器应该如何来避免这种情况出现？

客户端如何模拟高并发呢？

客户端运行初期完成所设定的一定量的<code>socket</code>创建和相应的处理线程的创建，然后使用条件变量来完成线程同步，直到最后一个线程创建完成，才向所有线程发出广播通知，让所有线程并发调用<code>connect</code>（这样相当于所有的客户端在同一时间请求连接，即高并发），连接成功则关闭连接，失败则返回。

关于 linux系统中进程所能创建的线程数目?

每个进程需要自己独立的栈空间，linux缺省的线程栈大小是10mb。在32位的机子上一个进程需要4g的内存空间，去掉自己的栈空间全局程序段空间，一般只有3g内存可以用，创建线程时就需要从这3g的空间中分配10m出来，所以最多可以分配300多个线程。

当然这里还可以使用多个进程，每个进程300个线程的方式来进一步扩大并发量。

当然64位系统中，此数值会不同，甚至会大很多

linux最大线程数限制及当前线程数查询： 总结系统限制有： <code>cat /proc/sys/kernel/pid_max</code> #查系统支持的最大线程数，一般会很大，相当于理论值 <code>cat /proc/sys/kernel/threads-max</code> <code>max_user_process</code>（<code>ulimit -u</code>） #系统限制某用户下最多可以运行多少进程或线程 <code>/proc/sys/vm/max_map_count</code> 硬件内存大小

我们在客户端程序中，为我们模拟每个客户端创建一个线程

1

2

3

4

5

6

7

8

9

10

11

然后在每个客户端线程中，创建并初始化客户端的套接字描述符。

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

条件变量是利用线程间共享的全局变量进行同步的一种机制，主要包括两个动作：一个线程等待”条件变量的条件成立”而挂起；另一个线程使”条件成立”（给出条件成立信号）。为了防止竞争，条件变量的使用总是和一个互斥锁结合在一起。

当然这里有个关键问题，就是如何保证模拟出来所有的客户端同步在连接服务器之前

在这里就使用条件变量进行同步。

条件变量初始化

在connect之前设置条件变量，

注意：阻塞返回后立即解锁，防止互斥量加锁带来的阻塞 <code>pthread_mutex_unlock(&amp;mut);</code>

当条件满足时，唤醒阻塞在条件变量上的线程：

综上，客户端模拟并发过程中没有存在不同步的情况导致上述性能问题。（注意，在广播的时候，会出现广播丢失的情况，所以需要多次执行广播操作才会使得所有线程执行任务，所以某种程度上这里并不能模拟完完全全的并发）

[注意] 客户端和服务器之间的连接是在同一台机器上，使用socket方式通信的话会经过127.0.0.1的回环线路，不会有网卡等硬件资源的访问性能消耗，所以不存在网络通信时延等问题。

性能问题主要发生在服务器，可能是以下几部分造成：

服务器的监听队列<code>listen(listenfd,xxx)</code>

参数2指定队列内所能容纳的元素的最大值，

当来不及从队列中移除元素时（调用accept移除或者tcp自动放弃）就会造成队列满而使得一些请求丢失。

解决办法

增大队列容量是一种办法，但是注意等待队列太会带来效率的性能缺陷，而且<code>listen</code>函数对最大队列容量有一个上限，大小为<code>somaxconn</code>，当然必要时刻我们可以修改这个常量的大小。

直接修改<code>listen</code>及相关函数的实现（比较麻烦，不建议），可以将<code>listen</code>所维护的队列修改为<code>linklist</code>，支持队列的动态增长。

<code>accept</code>导致阻塞过长时间，使得队列无法及时清空已经完成3次连接的<code>socket</code>

也就是任意两个<code>accept</code>之间的时间间隔是关键因素，如下面代码所示（一般来说，可以通过<code>listen</code>之后在循环调用<code>accept</code>来将已完成3次握手的连接从listen所维护的队列中移除。

解决办法：

* 两个accept之间尽量不要又多余的操作，使得accept返回后可以立刻执行下一个accept。经过试验，该方法可以较好的提高性能，减少connect的丢失数。

本质上这是一种“生产者-消费者”的模式，listen维护“已连接”和“待连接”的队列，当客户发出连接请求并最终连接成功时，在“已连接”队列中会生产一个“product”，然后这时候希望“消费者”也就是accept函数可以快速的从队列中消费这个“product”，这样就不会因为队列满而导致无法继续生产（也就是客户的connect会失效，导致上面队列长度10，300个并发connect带来的67个存活的情况），但是在本例情况下，我们无法控制生产者的疯狂生产行为，因为连接是客户发起的，这是不可预知的，所以我们如果想不修改listen函数来提高性能的话，那么就只能让消费者更加快的把产品消耗掉，使得listen队列可以容纳更多的新生产的产品，而第一种加快消费者消耗产品的方法就是a，第二种加快消费者消耗产品的方法是我们可以增加多几个消费者来帮忙消耗，但是这几个消费者间也要好好协调。第三种方法是让消费者把产品先移走为listen的队列腾出空间，再自行处理产品，如d所示。

使用多线程策略，每个线程独立调用accept。(花了一个上午的时候正glib的线程池，一直用不了，其他都正常，就是线程不启动，不知道会不会是bug)

修改listen和accept的实现方式，让listen所维护的队列可以智能的判断拥挤情况，从而对accept的调用做出调度，在队列繁忙时，使用多线程的方式让多个accept来移除队列中的元素，在队列空闲时，可以适当的调整accept的处理线程数，这也是一种线程池的实现。

修改accept的实现方式，在accept中实现一个“消费缓冲区”，为的是及时将listen中的队列元素移动到该缓冲区中，再由其他处理线程或者进程来对缓冲区中的元素进行处理，这个方法尽量让listen队列中已连接的socket可以被移除。这个方法比较上述方法来说是比较好的一种，但是还是需要修改已有的代码。

服务器短开辟一个线程池，线程完成与原来单线程的服务器执行相同的操作，accept接受客户端的请求，并且开辟线程进行响应进行

服务器线程池

线程池中的线程完成同原来服务器主线程完全相同的操作

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

526

527

528

529

530

531

532

533

534

535

536

转载：http://blog.csdn.net/gatieme/article/details/50828863