[Caideyipi]

Description

Several collection materialization paths already know how many entries they will append, but allocate default-sized containers. Large batches repeatedly grow and copy ArrayList backing arrays or resize hash tables.

Pre-size 132 collections in 74 production Java files across eight modules:

• Schema/path/plan deserialization, Pipe file-seal and handshake payloads, and progress metadata.
• Session batch-write buffers and schema lists, and JDBC result column metadata.
• Query projections, expression transformers, row-pattern evaluation, and spill readers.
• Memtable tablet schema lists and recovery, TsFile device sets, ConfigNode plans/procedures, subscription retention snapshots, and UDF pattern processing.

Use serialized entry counts or the exact number of outputs produced from the input. Keep optional empty lists at capacity zero and preserve their existing null/empty handling. Hash maps and sets use the existing Guava expected-size factories, which account for the default load factor and avoid capacity arithmetic overflow.

This is independent of #18845; its WAL metadata and subscription acknowledgement changes are not included.

Validation

• Spotless applied; Checkstyle, Spotless, and forbidden API checks passed during the reactor build.
• English reactor test-compile passed for the eight affected modules and their dependencies (30 modules).
• 47 existing test classes passed: 486 tests, zero failures/errors/skips. Coverage includes Session/JDBC, schema filters and paths, plan/procedure serialization, memtable partial inserts and recovery, expression/operator behavior, TsFile metadata, Pipe payloads, and UDF pattern matching.
• Chinese locale reactor test-compile passed for the same 30 modules with -P with-zh-locale.

A separate JDK 17 allocation experiment used shared, pre-boxed integer entries and ThreadMXBean.getThreadAllocatedBytes after warm-up. For constructing and filling 1,024 entries:

Container	Default capacity	Pre-sized	Allocation reduction
ArrayList	15,024 bytes	4,136 bytes	72.5%
HashMap	49,264 bytes	41,024 bytes	16.7%
HashSet	49,280 bytes	41,040 bytes	16.7%

These are container allocation measurements; cluster throughput has not been benchmarked.

• Self-reviewed.