释放双眼，带上耳机，听听看~！
在《Java NIO框架Netty教程（五）- 消息收发次数不匹配的问题》里我们试图分析一个消息收发次数不匹配的问题。当时笔者还是心存疑惑的。所以决定先学习一下Java NIO的Selector机制。
经过简单的了解，笔者大胆的猜测和“武断”一下该问题的原因。
首先，Selector机制让我们注册一个感兴趣的时间，然后只要有该时间发生，就会传递给接收端。我们写了三次，接收端一定会出发三次的。
然后，Netty实现机制里，有个Buffer缓冲池，把收到的信息都缓存在里面，通过一个线程统一处理。也就是我们看到的那个buffer的处理过程。
Netty的设置中，有一个一次性最多读取字节大小的设定。并且，事件的触发是在处理过缓冲池中的消息之后。我们再来回顾一下Netty中读取信息的那段代码：
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
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
2
3
4
5
6
7
8 try
9 {
10
11
12
13
14
15
16 while
17 ((ret = ch.read(bb)) >
18 0
19 ) {
20
21
22
23
24
25
26 readBytes += ret;
27
28
29
30
31
32
33 if
34 (!bb.hasRemaining()) {
35
36
37
38
39
40
41 break
42 ;
43
44
45
46
47
48
49 }
50
51
52
53
54
55
56 }
57
58
59
60
61
62
63 failure =
64 false
65 ;
66
67
68
69
70
71
72 }
73 catch
74 (ClosedChannelException e) {
75
76
77
78
79
80
81 // Can happen, and does not need a user attention.
82
83
84
85
86
87
88 }
89 catch
90 (Throwable t) {
91
92
93
94
95
96
97 fireExceptionCaught(channel, t);
98
99
100
101
102
103
104 }
105
106
107
108
109
110
111
112
113
114
115
116
117 if
118 (readBytes >
119 0
120 ) {
121
122
123
124
125
126
127 bb.flip();
128
129
130
131
132
133
134
135
136
137
138
139
140 final
141 ChannelBufferFactory bufferFactory =
142
143
144
145
146
147
148 channel.getConfig().getBufferFactory();
149
150
151
152
153
154
155 final
156 ChannelBuffer buffer = bufferFactory.getBuffer(readBytes);
157
158
159
160
161
162
163 buffer.setBytes(
164 0
165 , bb);
166
167
168
169
170
171
172 buffer.writerIndex(readBytes);
173
174
175
176
177
178
179
180
181
182
183
184
185 recvBufferPool.release(bb);
186
187
188
189
190
191
192
193
194
195
196
197
198 // Update the predictor.
199
200
201
202
203
204
205 predictor.previousReceiveBufferSize(readBytes);
206
207
208
209
210
211
212
213
214
215
216
217
218 // Fire the event.
219
220
221
222
223
224
225 fireMessageReceived(channel, buffer);
226
227
228
229
230
231
232 }
233 else
234 {
235
236
237
238
239
240
241 recvBufferPool.release(bb);
242
243
244
245
246
247
248 }
249
可以看到，如果没有读取到字节是不会触发事件的，所以我们可能会收到2次或者3次信息。（如果发的快，解析的慢，后两次信息，一次性读取了，就2次，如果发送间隔长，分次解析，就收到3次。）原因应该就是如此。跟我们开始猜的差不多，只是不敢确认。
如非特别注明，本站内容均为OneCoder原创，转载请务必注明作者和原始出处。
本文地址：链接地址
