synchronized 作为悲观锁的原因
synchronized 被归类为悲观锁，主要基于其设计理念和执行机制。悲观锁的核心思想是假设并发冲突频繁发生，因此在访问共享资源前会预先加锁，确保独占访问。以下是具体原因：
默认并发冲突假设
synchronized 的设计基于最坏情况假设，即认为多线程环境下共享资源的访问必然存在竞争。这种假设导致其在操作数据前直接加锁，阻止其他线程同时访问，避免潜在的数据不一致问题。
独占式锁机制
当线程进入 synchronized 修饰的代码块或方法时，会自动获取锁（对象监视器锁），其他线程必须等待锁释放才能继续执行。这种排他性特性是悲观锁的典型表现，强调"先加锁，后操作"的保守策略。
阻塞其他线程
如果锁已被占用，其他尝试获取锁的线程会被强制阻塞（进入 BLOCKED 状态），直到锁释放。这种阻塞行为是悲观锁实现线程安全的主要手段，与乐观锁（如 CAS 机制）的非阻塞重试形成对比。
适用场景
synchronized 适合高竞争场景，如多个线程频繁修改同一数据。悲观锁的优势在于简化了并发控制逻辑，但可能带来性能开销（如线程切换、等待时间）。
与乐观锁的对比
乐观锁（如 ReentrantLock 的尝试机制或 CAS）假设冲突较少，通过版本号或重试处理冲突。而 synchronized 不提供尝试机制，直接加锁，体现其悲观锁的本质。
总结：synchronized 的悲观锁特性体现在其默认加锁行为、独占访问机制以及对并发冲突的保守处理方式上。