（翻译www.java-performance.com）提高Java程序性能--JDK篇（三）

Regexp-related methods of String: java.util.regex.Pattern, java.util.regex.Matcher, java.lang.String: pattern/matcher logic:
1. 用Matcher和Pattern的函数来代替String中String.matches, split, replaceAll, replaceFirst函数的使用, 避免重复编译pattern。
2. 在Java7中，已经针对String.split函数进行了优化，如果分隔字符串不是正则表达式，尽管用String.split函数进行分隔。
3. 对于任何简单的情形，如果代码对时间要求高，尽量自己手写解析函数来代替Pattern函数，这可以轻松的提速10倍。

java.util.Date, java.util.Calendar and java.text.SimpleDateFormat performance: java.util.Date, java.util.Calendar, java.text.SimpleDateFormat: date storage, parsing and converting back to string:
1. 除非是不得已的情况，否则不要使用java.util.Date，可以使用long类型来代替它。
2. java.util.Calendar对于所有的日期计算和国际化都很方便，但是创建很花时间，也很占内存，所以避免大量的存储或创建这类对象。
3. java.text.SimpleDateFormat在解析日期和时间时很有用，但如果你有大量相同格式(尤其是没有时间)的日期需要解析时最好不要用它。可以自己手动实现一个解析器。

Joda Time library performance: org.joda.time.DateTime, org.joda.time.format.DateTimeFormat, org.joda.time.format.DateTimeFormatter.
This is a comparison of Joda Time library classes performance with standard JDK classes performance (java.util.Date, java.util.Calendar, java.text.SimpleDateFormat). I advice you to read this article in conjunction with a java.util.Date, java.util.Calendar and java.text.SimpleDateFormat performance article. This article was tested on Joda Time ver 2.1-2.3.
1. 所有的Joda Time/DateTime对象都是在long类型的时间戳上构建的，所以从long来构建这些对象开销很小。
2. Joda Time的2.1到2.3版本有一个关于时区偏移计算逻辑的性能问题（与夏令时有关，欧洲时区的影响更大）。In essence it means that all zones will perform badly in all years after Joda Time release you are using.
3. 如果没有被上面所说的问题所影响的时间的计算，Joda对象比GregorianCalendar快1.5到3倍，如果是被影响的那部分就会慢4倍。
4. Joda不像GregorianCalendar会在对象内部保存人工可读的时间（年月日时分秒），所以访问Joda对象的（年月日时分秒）的时候，如果访问多于一项时，代价会更大。
5. Joda的日期时间解析比JDK中的SimpleDateFormat快点，原因就是Joda构造解析器的代价非常小，所以再也不用缓存解析器了。

JSR 310 - Java 8 Date/Time library performance (as well as Joda Time 2.3 and j.u.Calendar): an overview of a new Java 8 date/time implementation also known as JSR-310 and its performance comparison with Joda Time 2.3 and j.u.GregorianCalendar.
1. Java8的日期时间类是在人工可读（年月日时分秒微秒）的基础上构建的。所以在人工可读方面的处理比较快。不过要是处理电脑使用的时间，尤其是在一个小的时间范围，用int/long来实现更快点。
2. Java8中getDayOfMonth之类的getter函数的复杂度是O(1)，Joda在这种场景下需要从电脑表示的时间向人可读时间的转换，这是Joda的一个瓶颈。
3. 在Java 8 ea b121中由于JDK内部异常的抛出与捕获，所以在处理OffsetDateTime/OffsetTime/ZonedDateTime时非常慢。

---

原文：

Regexp-related methods of String: java.util.regex.Pattern, java.util.regex.Matcher, java.lang.String: pattern/matcher logic:

Tags: low latency, high throughput, CPU optimization.

• Always (or nearly always) replace String.matches, split, replaceAll, replaceFirst methods with Matcher and Pattern methods - it will save you from unnecessary pattern compilation.
• In Java 7 splitting by a single not regex-special character string is optimized in String.split method. Always use String.split to split such strings in Java 7.
• In all other simple cases consider handwriting parsing methods for simple situations in the time-critical code. You can easily gain 10 times speedup by replacing Pattern methods with handcrafted methods.

java.util.Date, java.util.Calendar and java.text.SimpleDateFormat performance: java.util.Date, java.util.Calendar, java.text.SimpleDateFormat: date storage, parsing and converting back to string:

Tags: low latency, high throughput, finance, CPU optimization, memory optimization.

• Do not use java.util.Date unless you have to use it. Use an ordinary long instead.
• java.util.Calendar is useful for all sorts of date calculations and i18n, but avoid either storing a lot of such objects or extensively creating them - they consume a lot of memory and expensive to create.
• java.text.SimpleDateFormat is useful for general case datetime parsing, but it is better to avoid it if you have to parse a lot of dates in the same format (especially dates without time). Implement a parser manually instead.

Joda Time library performance: org.joda.time.DateTime, org.joda.time.format.DateTimeFormat, org.joda.time.format.DateTimeFormatter. 
This is a comparison of Joda Time library classes performance with standard JDK classes performance (java.util.Date, java.util.Calendar, java.text.SimpleDateFormat). I advice you to read this article in conjunction with a java.util.Date, java.util.Calendar and java.text.SimpleDateFormat performance article. This article was tested on Joda Time ver 2.1-2.3.

Tags: low latency, high throughput, finance, CPU optimization, memory optimization.

• All Joda Time date/time objects are built on top of a long timestamp, so it is cheap to construct those objects from a long.
• Joda Time ver 2.1-2.3 is affected by a performance issue in a timezone offset calculation logic - all years after the last daylight savings rule change in the given timezone use a slow calculation path (European timezones are affected particularly badly). In essence it means that all zones will perform badly in all years after Joda Time release you are using.
• Date/time objects construction and date/time arithmetics in Joda work 1.5-3 times faster than GregorianCalendar for the years not affected by an above mentioned performance issue. For affected years date operations performance in Joda plummets and could be 4 times slower than in GregorianCalendar.
• Joda does not keep the human time - year/month/day/hour/min/second inside its objects (unlike GregorianCalendar). It means that accessing human time on Joda objects is more expensive if you need to get more than one field.
• Date/time parsing in Joda is working a little faster than in JDK SimpleDateFormat. The advantage of Joda parsing is that constructing a parser - DateTimeFormatter object is extremely cheap, unlike an expensive SimpleDateFormat, so you don't have to cache parsers anymore.

JSR 310 - Java 8 Date/Time library performance (as well as Joda Time 2.3 and j.u.Calendar): an overview of a new Java 8 date/time implementation also known as JSR-310 and its performance comparison with Joda Time 2.3 and j.u.GregorianCalendar.

Tags: Java 8, overview, CPU optimization, memory optimization.

• Java 8 date/time classes are built on top of human time - year/month/day/hour/minute/second/nanos. It makes them fast for human datetime arithmetics/conversion. Nevertheless, if you are processing computer time (a.k.a. millis since epoch), especially computer time in a short date range (a few days), a manual implementation based onint/long values would be much faster.
• Date/time component getters like getDayOfMonth have O(1) complexity in Java 8 implementation. Joda getters require the computer-to-human time calcualtion on every getter call, which makes Joda a bottleneck in such scenarios.
• Parsing of OffsetDateTime/OffsetTime/ZonedDateTime is very slow in Java 8 ea b121 due to exceptions thrown and caught internally in the JDK.