- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 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
byte[] buffer = new byte[BUFFER_SIZE];
ReadState readState = ReadState.BOUNDARY;
InputStream input = request.getInputStream();
int read = input.read(buffer);
int pos = 0;
// This is a fail-safe to prevent infinite loops from occurring in some environments
int loopCounter = 20;
while (read > 0 && loopCounter > 0) {
for (int i = 0; i < read; i++) {
switch (readState) {
// Pos is calculated...
case BOUNDARY:
case HEADERS:
case DATA:
}
}
if (pos < read) {
// move the bytes that weren't read to the start of the buffer
int bytesNotRead = read - pos;
System.arraycopy(buffer, pos, buffer, 0, bytesNotRead);
read = input.read(buffer, bytesNotRead, buffer.length - bytesNotRead);
// Decrement loopCounter if no data was readable
if (read == 0) {
loopCounter--;
}
read += bytesNotRead;
} else {
read = input.read(buffer);
}
}
Кусок исходников из недров JBoss Seam(наткнулся профайлером).
Пацаны пофиксили багу с бесконечным циклом и 100 утилизацией CPU.
Весь класс:
https://www.java2s.com/Open-Source/Java/JBoss/jboss-seam-2.2.0/org/jboss/seam/web/MultipartRequestImpl.java.htm
Версия с бесконечным циклом:
http://www.docjar.com/html/api/org/jboss/seam/web/MultipartRequestImpl.java.html
Dummy00001 17.02.2013 00:30 # 0
признаюсь что сам не раз такое делал. только я как правило лимит итераций ставлю повыше и какую ошибку генерю. пару раз даже помогало настоящие баги отловливать.
в случаях когда это касается продашн кода, и цикл зависит полностью от пользовательских данных, часто просто по другому отловить проблему и не невозможно.