如何判断类对象创建成本？SimpleDateFormat创建开销高在哪？

Great question! Let's break this down into clear, actionable parts to make it easier to understand.

There are a few key signals to look for when judging if creating an instance of a class is expensive:

• Heavy initialization logic in constructors: If the class’s constructor does complex computations (like parsing large configuration files, processing regex patterns, or initializing large in-memory data structures), or if it inherits from parent classes that also have costly initialization steps, the creation cost is likely high.
• Scarce resource allocation: If creating the object requires acquiring limited resources (such as direct memory buffers, file handles, or database connections), or if it depends on other objects that are themselves expensive to create, this adds to the overall cost.
• Profiling and benchmark data: The most concrete way is to use performance profiling tools (like VisualVM, JProfiler, or even simple JMH benchmarks). If object creation shows up as a significant CPU or memory hotspot in your application’s critical paths, that’s a clear sign of high creation cost.
• Cumulative overhead from frequent creation: Even if a single instance creation isn’t extremely slow, if you’re creating thousands of instances in a short period (e.g., inside a loop or in high-throughput web requests), the cumulative overhead becomes meaningful.

SimpleDateFormat is a classic example of a thread-unsafe class with surprisingly high creation overhead. Here’s why:

• Pattern and locale parsing: When you instantiate SimpleDateFormat, it has to parse your input pattern string (like yyyy-MM-dd HH:mm:ss)—this involves regex matching, building internal rule structures for date/time formatting, and loading locale-specific resources (like month/day names, timezone rules). All these steps are non-trivial.
• Dependency on heavyweight helper classes: SimpleDateFormat relies on Calendar and NumberFormat instances under the hood. Creating a Calendar involves initializing timezone data and locale-specific calendar rules, while NumberFormat loads localized number formatting configurations—both of which have their own significant overhead.
• Complex internal state setup: The class initializes a DateFormatSymbols object, which holds a large set of locale-specific date/time strings (short/long month names, weekday names, etc.). Loading and populating this structure during creation adds to the cost.

This builds on the general high-cost object checks, but with a focus on multi-threaded reuse scenarios:

• Compare creation vs reuse overhead: If using the class requires creating a new instance every time (because it’s thread-unsafe), and you’re using it frequently across threads, calculate the cumulative cost. For example, creating a SimpleDateFormat per web request adds up quickly in a high-traffic app.
• Inspect constructor and initialization code: Look at what the class does when it’s created. If the constructor reads files, makes network calls, or performs heavy computations, it’s a strong indicator of high creation cost.
• Run targeted benchmarks: Use tools like JMH to measure how long it takes to create a new instance versus reusing an existing one. If creation time is an order of magnitude (or more) slower than reusing, then ThreadLocal is a great fit to avoid redundant creation.

内容的提问来源于stack exchange，提问作者sdindiver