1. 生产级代码的核心特征解析当我们需要将一个原型或实验性代码升级为生产级实现时必须跨越几个关键的技术门槛。生产环境与开发环境最大的区别在于生产代码需要7×24小时稳定运行处理各种边界条件和异常情况同时保持高性能和可维护性。线程安全是生产级代码的首要特征。在多线程环境下任何共享资源的访问都必须通过适当的同步机制进行保护。但同步机制的选择需要权衡——过度同步会导致性能下降同步不足则会产生竞态条件。我曾在一个电商平台的库存系统中因为未对库存计数器做原子操作保护导致在高并发场景下出现超卖现象。后来通过将int改为AtomicInteger才解决问题。死锁预防是另一个关键点。死锁的四个必要条件互斥、占有且等待、非抢占、循环等待中打破任意一个即可避免死锁。在实际项目中我习惯使用锁排序技术——对所有需要获取多个锁的场景严格规定锁的获取顺序。例如在银行转账系统中总是先锁账户ID小的再锁大的这样就避免了循环等待的可能性。内存管理方面生产级代码必须杜绝内存泄漏和内存爆炸。在Java中最容易出现内存问题的是缓存实现和集合类使用。我曾排查过一个线上事故由于使用HashMap做缓存且没有设置上限最终导致OOM。解决方案是改用LinkedHashMap并重写removeEldestEntry方法实现LRU淘汰策略。2. 线程安全实现深度剖析2.1 同步机制选型指南现代编程语言提供了多种同步原语每种都有其适用场景synchronized关键字适合简单的临界区保护ReentrantLock支持尝试获取锁、公平锁等高级特性ReadWriteLock适合读多写少的场景StampedLockJava8新增进一步优化读性能原子类(AtomicInteger等)适合简单的原子操作在电商价格计算服务中我最初使用synchronized保护价格缓存但在大促期间出现了严重的性能瓶颈。后来改用ReadWriteLockQPS从200提升到了1500。关键代码片段private final ReadWriteLock rwLock new ReentrantReadWriteLock(); private final MapString, BigDecimal priceCache new HashMap(); public BigDecimal getPrice(String sku) { rwLock.readLock().lock(); try { return priceCache.get(sku); } finally { rwLock.readLock().unlock(); } } public void updatePrice(String sku, BigDecimal price) { rwLock.writeLock().lock(); try { priceCache.put(sku, price); } finally { rwLock.writeLock().unlock(); } }2.2 线程封闭技术除了同步机制另一种实现线程安全的方法是避免共享——即线程封闭。ThreadLocal是典型的线程封闭实现但使用时需要注意内存泄漏问题。最佳实践是声明为static final保证单例使用后及时调用remove()清理避免存储大对象在用户会话管理中我使用ThreadLocal保存用户信息但曾因为未及时清理导致内存泄漏。正确的实现方式public class UserContextHolder { private static final ThreadLocalUser holder new ThreadLocal(); public static void set(User user) { holder.set(user); } public static User get() { return holder.get(); } public static void clear() { holder.remove(); // 必须清理 } } // 在过滤器或拦截器中确保清理 try { UserContextHolder.set(currentUser); // 业务逻辑 } finally { UserContextHolder.clear(); }3. 死锁预防与排查实战3.1 死锁预防四原则根据多年的调优经验我总结出以下死锁预防原则锁排序原则所有线程按固定顺序获取锁锁时限原则尝试获取锁时设置超时如tryLock资源预分配一次性获取所有需要的资源开放调用不在持有锁的情况下调用外部方法在分布式锁场景中我曾遇到过一个典型死锁服务A持有锁1等待锁2服务B持有锁2等待锁1。解决方案是引入全局锁排序并设置锁获取超时public void transfer(Account from, Account to, BigDecimal amount) { // 确定锁获取顺序 Account firstLock from.getId() to.getId() ? from : to; Account secondLock from.getId() to.getId() ? to : from; try { if (firstLock.getLock().tryLock(1, TimeUnit.SECONDS)) { try { if (secondLock.getLock().tryLock(1, TimeUnit.SECONDS)) { try { // 转账逻辑 } finally { secondLock.getLock().unlock(); } } } finally { firstLock.getLock().unlock(); } } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }3.2 死锁排查工具链当系统出现死锁时我们需要专业的工具进行诊断Javajstack、VisualVM、ArthasMySQLSHOW ENGINE INNODB STATUSSQL Server系统视图sys.dm_tran_locksGrafana配合Prometheus监控锁等待时间一个典型的Java死锁分析过程使用jps获取Java进程ID执行jstack -l pid thread_dump.txt在输出中搜索deadlock关键词分析死锁线程的堆栈和锁持有情况我曾用Arthas快速诊断过一个线上死锁问题关键命令thread -b // 直接定位死锁线程 monitor -c 5 java.util.concurrent.locks.ReentrantLock getQueueLength // 监控锁竞争情况4. 内存安全最佳实践4.1 内存泄漏防护生产环境中常见的内存泄漏场景静态集合持有对象引用未关闭的资源连接、流等监听器未注销线程池未正确关闭在金融系统中我们曾因为缓存使用不当导致内存泄漏。最终采用的解决方案public class SafeCacheK, V { private final MapK, V cache new LinkedHashMapK, V() { Override protected boolean removeEldestEntry(Map.EntryK, V eldest) { return size() 1000; // 控制缓存大小 } }; private final ReentrantReadWriteLock lock new ReentrantReadWriteLock(); public void put(K key, V value) { lock.writeLock().lock(); try { cache.put(key, value); } finally { lock.writeLock().unlock(); } } public V get(K key) { lock.readLock().lock(); try { return cache.get(key); } finally { lock.readLock().unlock(); } } }4.2 内存爆炸预防内存爆炸通常由以下原因引起大对象直接加载到内存未分页的数据库查询递归调用无终止条件不合理的缓存策略在处理大数据导出功能时我们采用流式处理避免OOMpublic void exportBigData(OutputStream out) throws IOException { try (Connection conn dataSource.getConnection(); Statement stmt conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY)) { stmt.setFetchSize(1000); // 分批获取 ResultSet rs stmt.executeQuery(SELECT * FROM huge_table); CSVWriter writer new CSVWriter(new OutputStreamWriter(out)); while (rs.next()) { String[] row // 转换逻辑 writer.writeNext(row); } } }5. 生产级代码的终极形态综合所有考量因素一个生产级的线程安全、无死锁、无内存问题的代码框架应该包含以下要素资源管理public class ResourceHolder implements AutoCloseable { private final Lock lock new ReentrantLock(); private final Resource resource; public ResourceHolder() { this.resource new Resource(); } public void execute() { lock.lock(); try { // 临界区操作 } finally { lock.unlock(); } } Override public void close() { lock.lock(); try { resource.cleanup(); } finally { lock.unlock(); } } } // 使用try-with-resources确保资源释放 try (ResourceHolder holder new ResourceHolder()) { holder.execute(); }并发控制public class ConcurrentService { private final Executor executor Executors.newFixedThreadPool( Runtime.getRuntime().availableProcessors() * 2, new ThreadFactoryBuilder() .setNameFormat(worker-%d) .setUncaughtExceptionHandler((t, e) - logger.error(Thread {} failed, t.getName(), e)) .build()); private final RateLimiter rateLimiter RateLimiter.create(1000.0); public CompletableFutureResult process(Request request) { return CompletableFuture.supplyAsync(() - { rateLimiter.acquire(); // 限流 // 处理逻辑 return new Result(); }, executor); } }防御性编程public class RobustComponent { private final Object lock new Object(); GuardedBy(lock) private State state; public void safeOperation() { synchronized (lock) { if (state ! State.VALID) { throw new IllegalStateException(Invalid state); } // 核心逻辑 } } public void timeoutOperation(long timeout, TimeUnit unit) throws TimeoutException { long start System.nanoTime(); synchronized (lock) { while (state ! State.READY) { long remaining unit.toNanos(timeout) - (System.nanoTime() - start); if (remaining 0) { throw new TimeoutException(); } try { TimeUnit.NANOSECONDS.timedWait(lock, remaining); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(Interrupted, e); } } // 操作逻辑 } } }在实际项目中使用这些模式时需要特别注意锁的粒度要尽可能细同步块内的操作要尽可能少避免在同步块内调用可能阻塞的方法使用final字段保证安全发布对共享变量使用volatile或原子类