Alternatives to FastDateFormat for efficient date parsing?

后端 未结 6 923
-上瘾入骨i
-上瘾入骨i 2021-02-05 04:29

Well aware of performance and thread issues with SimpleDateFormat, I decided to go with FastDateFormat, until I realized that FastDateFormat

相关标签:
6条回答
  • 2021-02-05 05:10

    Do you really need to parse dates that quickly? Have you tested SimpleDateFormat and found it too slow for your needs?

    Note, there are a variety of ways to cache slow-to-construct, non-thread-safe class instances (e.g. ThreadLocal, pools).

    0 讨论(0)
  • 2021-02-05 05:13

    Note that since commons-lang 3.2, FastDateFormat supports parsing as well as printing.

    See: http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/time/FastDateFormat.html

    0 讨论(0)
  • 2021-02-05 05:14

    As of Java 8, one can use DateTimeFormatter along with the the Java 8 Time API to both parse and format dates. From the documentation:

    This class is immutable and thread-safe.

    It's recommended to use this class if possible for new work going forward instead of using SimpleDateFormat.

    0 讨论(0)
  • 2021-02-05 05:15

    Found something interesting here of this case in Android: http://andmob.wikidot.com/faq-simpletimeformat

    SimpleDateFormat, the first time you try parsing (or, presumably, formatting) a date, will load in all the timezone data for your locale. This will take 2-3 seconds. It is hoped that this will be fixed in some future edition of Android.

    In the interim, consider using AsyncTask to "warm up" SimpleDateFormat in your process before you need it. Just parse some date in the AsyncTask doInBackground() to get it to load the timezones sometime when it will not impact the user so much. Once initialized in your process, SimpleDateFormat will run quickly until your process is terminated.

    0 讨论(0)
  • 2021-02-05 05:25

    At a best guess, it's to keep FastDateFormat... well... fast, by limiting it to display only.

    Apache Commons DateUtils has a parseDate function, but that uses SimpleDateFormat internally.

    An alternative is to use the JodaTime library. It's a complete replacement for dealing with DateFormat, Date, and Calendar objects.

    JodaTime has a DateTimeFormatter that can be used to create DateTime objects (JodaTime's equivalent of Java's Date objects) from strings.

    An example of how to use it is like this:

    String strInputDateTime = "2010-12-27"; // An example, this would really come from outside
    DateTimeFormatter fmt = DateTimeFormat.forPattern("yyyy-MM-dd");
    DateTime dt = fmt.parseDateTime(strInputDateTime);
    

    I don't know if this is really any faster than SimpleDateFormat, though.

    0 讨论(0)
  • 2021-02-05 05:35

    The 'problem' with SimpleDateFormat is not performance, its thread safety.

    If you have thousands of threads and synchronizing is not an issue use synchronized (you can also pool the instances to alleviate this a little)

    If you have a reasonable amount of threads the recommended way is to have a separate instance for each SimpleDateFormat.

    UPDATE

    As of Java 8, just use DateTimeFormatter. It is immutable, thread safe, faster, and more flexible. (It also offers nice features like default patterns for ISO-8601 date/time strings.)

    0 讨论(0)
提交回复
热议问题