1. 项目概述一个轻量级Java事务管理器的诞生如果你在Java后端开发领域摸爬滚打超过三年大概率已经对Spring的声明式事务管理Transactional习以为常了。它确实强大但有时候尤其是在构建一些需要极致轻量、或者对Spring全家桶有“洁癖”的中间件、工具库时引入整个Spring框架仅仅为了事务管理感觉就像为了喝杯牛奶而养了一头牛。几年前我在参与一个高性能数据同步组件的开发时就遇到了这个困境。我们需要在非Spring环境中对跨多个数据库连接的操作进行原子性控制但又不想引入任何重量级框架。市面上的一些独立事务管理器要么功能臃肿要么文档稀缺。于是一个念头诞生了能不能自己动手造一个纯粹、简单、可插拔的Java事务管理器这就是ckanner/jta这个项目最初的由来。ckanner/jta不是一个对标完整JTAJava Transaction API规范的庞然大物它的目标非常聚焦提供一个轻量级、无依赖的核心让你能在非Spring、甚至非Java EE的纯Java SE环境中以类似Transactional的声明式或编程式方式管理本地事务主要是JDBC。它适合那些开发独立Java应用、嵌入式系统、特定中间件或者希望将事务管理逻辑从Spring中剥离出来进行更底层控制的开发者。简单说它就是为“场景简单但要求控制精细”的场合准备的瑞士军刀。2. 核心设计思路与架构拆解2.1 为什么是“轻量级”和“无依赖”在项目启动前我们做了明确的边界划定。完整的JTA规范涉及事务管理器Transaction Manager、资源管理器Resource Manager如数据库、应用服务器之间的复杂交互需要支持XA两阶段提交这必然会引入对javax.transactionAPI 的依赖以及复杂的资源管理。这对于我们的目标场景——管理单个或多个非XA数据源即普通JDBC连接的本地事务——来说过重了。因此ckanner/jta的核心设计原则第一条就是零外部依赖除了JDK和JDBC。这意味着项目本身不依赖Spring、不依赖任何应用服务器提供的JTA实现、不依赖特定的连接池。它只基于标准的java.sql.Connection接口和JDBC驱动工作。这样做的好处是极致的可移植性和嵌入性你可以把它打包进任何一个Java 8的应用中而不用担心依赖冲突或环境兼容性问题。2.2 核心抽象TransactionManager 与 Transaction尽管轻量但基本的事务抽象必须清晰。项目核心围绕两个接口展开TransactionManager这是事务的大脑负责事务生命周期的管理——开始begin、提交commit、回滚rollback、挂起suspend、恢复resume。我们的实现类JdbcTransactionManager是核心。Transaction代表一个具体的事务上下文持有当前事务关联的数据库连接Connection及其状态活跃、已提交、已回滚、仅回滚标记等。我们内部有一个JdbcTransaction类来实现它。关键设计点在于连接绑定Connection Binding。为了让在事务内部执行的数据库操作都能自动获取到同一个连接我们需要将Transaction对象与当前执行线程ThreadLocal绑定。同时这个Transaction内部也持有从数据源获取的真正Connection。这样当你在事务方法中通过工具类获取连接时拿到的一直是同一个。// 简化的核心绑定逻辑示意 public class TransactionSynchronizationManager { private static final ThreadLocalTransaction currentTransaction new ThreadLocal(); public static Connection getResource(DataSource dataSource) { Transaction tx currentTransaction.get(); if (tx ! null tx.isActive()) { // 从事务上下文中返回绑定的连接 return tx.getConnection(dataSource); } // 非事务环境下返回新的独立连接 return dataSource.getConnection(); } }2.3 声明式事务的魔法基于AOP的拦截仅仅有编程式事务手动 begin/commit还不够方便我们的目标是声明式。在Spring中这是通过AOP面向切面编程实现的。在无Spring环境下我们同样可以借助轻量级的AOP库例如AspectJ或者ByteBuddy来实现类似的功能。ckanner/jta选择了一种更灵活的方式提供标准的注解和拦截接口允许你集成任何你喜欢的AOP框架。项目定义了一个Transactional注解为避免冲突可命名为JtaTransactional其属性包括传播行为Propagation、隔离级别Isolation、只读标记readOnly等。同时提供了一个TransactionInterceptor类它包含了事务增强的核心逻辑在方法执行前创建或加入事务执行后提交或回滚。public class TransactionInterceptor implements MethodInterceptor { private TransactionManager transactionManager; public Object invoke(MethodInvocation invocation) throws Throwable { // 1. 解析方法上的 JtaTransactional 注解 JtaTransactional txAttr parseAnnotation(invocation.getMethod()); // 2. 根据传播行为决定是创建新事务、加入已有事务还是非事务执行 TransactionStatus status transactionManager.getTransaction(txAttr); try { // 3. 执行业务方法 Object result invocation.proceed(); // 4. 成功则提交 transactionManager.commit(status); return result; } catch (Exception e) { // 5. 失败则根据回滚规则决定是否回滚 if (shouldRollback(e, txAttr)) { transactionManager.rollback(status); } else { transactionManager.commit(status); } throw e; } } }你需要做的就是用你选择的AOP工具比如使用AspectJ的Aspect注解或者使用ByteBuddy创建动态代理将这个拦截器织入到带有JtaTransactional注解的方法上。这种设计让ckanner/jta的核心保持了纯净而将AOP框架的选择权交给了使用者。3. 核心功能模块深度解析3.1 事务传播行为的七种武器传播行为是事务管理中最精妙也最容易出错的部分。ckanner/jta完整实现了与Spring类似的七种传播行为这是它的核心价值之一。我们来深入理解每一种以及它们是如何在轻量级环境中实现的。REQUIRED默认如果当前存在事务则加入该事务如果不存在则创建一个新事务。这是最常用的。实现上TransactionManager.getTransaction()方法会检查当前线程是否已有绑定的事务通过ThreadLocal。有则返回一个代表“加入”的TransactionStatus无则新建事务并绑定。REQUIRES_NEW无论当前是否存在事务都创建一个新事务。新事务与旧事务完全独立拥有独立的连接和提交/回滚点。实现难点在于事务的挂起与恢复。当执行REQUIRES_NEW时需要将当前线程绑定的现有事务如果有挂起suspend将其信息如连接从ThreadLocal中取出并暂存然后创建并绑定新事务。新事务完成后再恢复resume旧事务。这里必须确保连接被正确归还和重新绑定否则会导致连接泄露或数据混乱。// 挂起逻辑简化示意 public TransactionStatus suspend() { Transaction currentTx currentTransaction.get(); if (currentTx ! null) { currentTransaction.remove(); // 从线程解绑 // 注意这里不能关闭连接连接由挂起的事务对象持有 return new SuspendedTransactionStatus(currentTx); } return null; }NESTED如果当前存在事务则在当前事务的嵌套子事务中执行。子事务是父事务的一部分其回滚只影响自身操作不影响父事务但父事务回滚会导致子事务一起回滚。这在JDBC中是通过保存点Savepoint实现的。实现时在进入NESTED方法时在当前连接的当前事务中创建一个保存点connection.setSavepoint()。方法执行成功释放保存点执行失败回滚到该保存点connection.rollback(savepoint)。这要求底层数据库驱动支持保存点。SUPPORTS如果当前存在事务则加入如果不存在则以非事务方式执行。实现简单检查当前线程绑定状态即可。NOT_SUPPORTED以非事务方式执行。如果当前存在事务则将其挂起待方法执行完毕后再恢复。实现类似REQUIRES_NEW但新创建的“事务”实际上是一个空壳不绑定真实连接所有数据库操作自动提交。NEVER必须在非事务环境下执行如果当前存在事务则抛出异常。这是一个严格的检查性行为。MANDATORY必须在已有事务中执行如果当前没有事务则抛出异常。常用于确保某些关键操作一定在事务管控之下。实操心得传播行为的选择绝大多数业务方法使用REQUIRED即可。REQUIRES_NEW常用于日志记录、异步消息发送等需要独立提交、不受主业务失败影响的场景但要小心因此导致的连接数暴增和死锁风险。NESTED是一个很好的折中可以部分回滚但数据库支持是前提。NOT_SUPPORTED可用于在事务方法中调用那些不支持事务的存储过程或特殊SQL。3.2 连接管理与资源同步事务管理的本质是对连接Connection生命周期的管理。ckanner/jta需要解决几个关键问题连接的获取与释放事务开始时从数据源获取连接事务结束后提交或回滚关闭连接归还到连接池。连接的线程绑定确保同一事务线程内的所有数据访问使用同一个连接。跨传播行为的连接传递在REQUIRED或NESTED传播行为下子方法如何获取到父方法开启的连接。我们的解决方案是TransactionSynchronizationManager 资源持有器ResourceHolder。资源持有器我们定义一个ConnectionHolder类它包装了真正的Connection对象并增加了一些控制属性如referenceCount引用计数。引用计数用于处理同一连接在嵌套事务或多次获取时的场景只有当引用计数归零时才真正关闭连接。同步管理器TransactionSynchronizationManager使用ThreadLocal维护两个核心映射MapDataSource, ConnectionHolder将数据源与实际使用的连接持有器绑定。ListTransactionSynchronization事务同步回调列表用于在事务完成前后执行清理或回调操作如关闭临时资源。当一个事务方法首次需要连接时TransactionManager会通过TransactionSynchronizationManager将ConnectionHolder绑定到当前线程。后续在同一事务内的任何地方通过DataSourceUtils.getConnection(DataSource)这是项目提供的一个工具类获取连接时都会返回这个已绑定的连接并将其引用计数加1。方法执行完毕在拦截器的finally块中会调用DataSourceUtils.releaseConnection将引用计数减1并进行可能的解绑和关闭操作。3.3 回滚规则的精细化控制默认情况下只有运行时异常RuntimeException和错误Error会导致事务回滚受检异常Checked Exception不会。但业务中我们常常需要更精细的控制。ckanner/jta的JtaTransactional注解提供了rollbackFor和noRollbackFor属性。实现原理是在TransactionInterceptor的捕获异常环节进行异常类型的匹配判断。不仅比较异常类本身还需要比较其所有父类直到Throwable以确定是否命中回滚规则。private boolean shouldRollback(Throwable ex, JtaTransactional txAttr) { // 1. 优先检查 noRollbackFor if (txAttr.noRollbackFor() ! null) { for (Class? excClass : txAttr.noRollbackFor()) { if (excClass.isAssignableFrom(ex.getClass())) { return false; // 明确指定不回滚 } } } // 2. 检查 rollbackFor if (txAttr.rollbackFor() ! null) { for (Class? excClass : txAttr.rollbackFor()) { if (excClass.isAssignableFrom(ex.getClass())) { return true; // 明确指定回滚 } } } // 3. 默认规则RuntimeException 和 Error 回滚 return (ex instanceof RuntimeException || ex instanceof Error); }注意事项异常捕获的粒度在拦截器中invocation.proceed()的调用必须被try-catch包裹并且catch的类型最好是Throwable而不是Exception。因为Error如OutOfMemoryError也需要触发回滚防止数据不一致。同时在回滚后一定要记得将异常原样抛出throw e不要吞掉否则调用方无法感知业务失败。4. 集成与实战让 jta 在你的项目中跑起来4.1 环境准备与基础配置假设我们有一个基于Maven的纯Java SE项目使用HikariCP作为连接池MySQL数据库。首先引入ckanner/jta假设它已发布到Maven中央仓库这里用示例坐标。dependency groupIdio.github.ckanner/groupId artifactIdjta-core/artifactId version1.0.0/version /dependency !-- 选择你喜欢的AOP框架例如AspectJ -- dependency groupIdorg.aspectj/groupId artifactIdaspectjweaver/artifactId version1.9.7/version /dependency接下来我们需要配置核心的TransactionManager和DataSource。通常我们会创建一个配置类用单例模式管理它们。public class TransactionConfig { private static DataSource dataSource; private static TransactionManager transactionManager; static { // 1. 配置数据源 (以HikariCP为例) HikariConfig config new HikariConfig(); config.setJdbcUrl(jdbc:mysql://localhost:3306/test_db); config.setUsername(root); config.setPassword(password); config.setMaximumPoolSize(10); dataSource new HikariDataSource(config); // 2. 创建事务管理器并注入数据源 transactionManager new JdbcTransactionManager(dataSource); } public static DataSource getDataSource() { return dataSource; } public static TransactionManager getTransactionManager() { return transactionManager; } }4.2 与AspectJ集成实现声明式事务我们选择使用AspectJ的编译时织入CTW或加载时织入LTW来集成事务拦截器。首先需要编写一个切面类。Aspect public class TransactionAspect { private TransactionInterceptor transactionInterceptor; public TransactionAspect() { // 初始化拦截器并注入事务管理器 this.transactionInterceptor new TransactionInterceptor(); this.transactionInterceptor.setTransactionManager(TransactionConfig.getTransactionManager()); } Around(annotation(io.github.ckanner.jta.annotation.JtaTransactional)) public Object manageTransaction(ProceedingJoinPoint joinPoint) throws Throwable { // 将AspectJ的JoinPoint适配成我们拦截器需要的MethodInvocation MethodInvocationAdapter invocation new MethodInvocationAdapter(joinPoint); // 委托给我们的TransactionInterceptor处理 return transactionInterceptor.invoke(invocation); } }这里需要一个简单的适配器MethodInvocationAdapter将AspectJ的ProceedingJoinPoint转换成我们拦截器定义的通用MethodInvocation接口。然后需要在META-INF/aop.xml文件中配置AspectJ织入器或者使用Maven插件进行编译时织入。以加载时织入为例在启动JVM时添加参数-javaagent:path/to/aspectjweaver.jar。4.3 编程式事务的使用场景虽然声明式事务很方便但在一些复杂逻辑中编程式事务能提供更精确的控制。ckanner/jta也提供了简洁的编程式API。public class OrderService { private TransactionManager tm TransactionConfig.getTransactionManager(); private DataSource dataSource TransactionConfig.getDataSource(); public void complexOrderProcess(Order order, ListItem items) throws Exception { // 开启一个新事务获取事务状态 TransactionStatus status tm.begin(TransactionDefinition.PROPAGATION_REQUIRED, TransactionDefinition.ISOLATION_READ_COMMITTED); Connection conn DataSourceUtils.getConnection(dataSource); // 获取事务性连接 try { // 1. 插入订单主表 orderDao.insert(order, conn); // 2. 循环插入订单明细 for (Item item : items) { item.setOrderId(order.getId()); itemDao.insert(item, conn); // 3. 更新库存这里可能调用另一个Service演示编程式嵌套 updateInventory(item.getSku(), item.getQuantity(), conn); } // 所有操作成功提交事务 tm.commit(status); } catch (Exception e) { // 任何失败回滚事务 tm.rollback(status); throw e; } finally { // 务必释放连接内部会判断是否在事务中决定关闭还是归还 DataSourceUtils.releaseConnection(conn, dataSource); } } private void updateInventory(String sku, int quantity, Connection conn) throws SQLException { // 这里演示在编程式事务内部手动控制一个小的逻辑单元 // 可以使用保存点实现嵌套回滚 Savepoint savepoint conn.setSavepoint(update_inventory); try { inventoryDao.decrease(sku, quantity, conn); // 可能还有其他校验逻辑... } catch (BusinessException e) { // 库存不足等业务异常只回滚库存更新操作 conn.rollback(savepoint); throw e; } } }实操心得编程式 vs 声明式声明式事务简洁、非侵入适合大多数标准的CRUD操作和业务方法。编程式事务则适用于以下场景1) 需要根据运行时条件动态决定是否开启/提交事务2) 需要精细控制事务边界比如在一个方法内分阶段提交3) 需要与复杂的异步任务或非JDBC资源如文件操作协同但这些操作本身无法被AOP拦截。在编程式事务中要特别注意连接的获取和释放必须通过DataSourceUtils否则会破坏事务绑定。5. 高级特性与扩展点5.1 多数据源事务管理非XA在实际项目中连接多个数据库是常见需求。ckanner/jta通过ChainedTransactionManager的概念来支持简单的多数据源事务。注意这不是分布式事务XA而是顺序事务。其原理是按照配置的顺序依次管理每个数据源的事务。提交时也按顺序提交但如果某个数据源提交失败它无法自动回滚之前已提交的数据源的事务。public class MultiDataSourceConfig { public static TransactionManager multiTxManager() { DataSource ds1 createDataSource1(); DataSource ds2 createDataSource2(); TransactionManager tm1 new JdbcTransactionManager(ds1); TransactionManager tm2 new JdbcTransactionManager(ds2); // 创建链式事务管理器 return new ChainedTransactionManager(tm1, tm2); } } // 使用时事务会先开启ds1的事务再开启ds2的事务。提交时先提交tm2再提交tm1后开启的先提交。警告这种模式存在数据不一致的风险。如果tm2提交成功但tm1提交失败那么ds2的数据已持久化无法撤回。因此它仅适用于对数据一致性要求不那么严格或者能通过业务逻辑进行最终补偿的场景。对于严格的分布式事务应寻求支持XA的数据库驱动和真正的JTA实现。5.2 事务同步与回调机制事务同步TransactionSynchronization是一个强大的扩展点允许你在事务完成的关键节点提交前、提交后、回滚后、完成清理后插入自定义逻辑。这在以下场景非常有用清理线程局部变量比如清除ThreadLocal中的缓存。发送事务性事件只有在事务成功提交后才发送消息到消息队列。记录审计日志将操作日志与事务绑定同生共死。public class AuditLogSynchronization implements TransactionSynchronization { private ListAuditLog logs new ArrayList(); public void addLog(AuditLog log) { logs.add(log); } Override public void beforeCommit(boolean readOnly) { // 提交前可以做一些最后检查但不要在此修改数据 for (AuditLog log : logs) { log.setCommitTime(new Date()); } } Override public void afterCommit() { // 事务已成功提交现在是安全执行后续操作的时候 // 例如将审计日志异步写入另一个系统或发送事件 auditLogService.saveAll(logs); // 假设这个服务调用是幂等的 } Override public void afterCompletion(int status) { // 无论提交还是回滚最终都会调用。status指示了最终状态。 // 可以在这里做资源清理 logs.clear(); TransactionSynchronizationManager.unbindResourceIfPossible(...); } } // 在业务代码中注册同步 public void doBusiness() { // ... 业务操作 AuditLogSynchronization sync new AuditLogSynchronization(); sync.addLog(new AuditLog(操作了XXX)); TransactionSynchronizationManager.registerSynchronization(sync); }5.3 自定义隔离级别与超时设置JtaTransactional注解支持设置隔离级别和超时时间。隔离级别直接映射到JDBCConnection的setTransactionIsolation方法。需要注意的是在事务传播过程中如果新事务的隔离级别与当前不同实现上可能需要挂起当前连接并用新隔离级别重新获取或复用连接这取决于数据库驱动对同一连接上隔离级别动态切换的支持程度。实践中建议在事务开始时就确定好隔离级别。超时设置这是一个“尽力而为”的特性。JDBC规范没有标准的API来设置事务超时。ckanner/jta的实现通常是在事务开始时记录一个时间戳并在事务操作间歇如每次获取连接或执行语句前后进行检查。如果超时则在下一个检查点抛出异常并触发回滚。这依赖于业务代码的执行频率对于长时间休眠的线程可能无法及时中断。更可靠的超时控制需要结合数据库层面的SET STATEMENT_TIMEOUT如果数据库支持或应用层的线程中断机制。6. 生产环境问题排查与性能调优6.1 常见问题与解决方案速查表问题现象可能原因排查步骤与解决方案事务未生效数据未回滚1. AOP织入失败拦截器未起作用。2. 异常类型不符合回滚规则如受检异常未配置。3. 方法内部捕获了异常未抛出。4. 使用了try-catch-finally并在catch中吃了异常。1. 检查AOP配置确保切面被加载可用调试查看方法是否被代理。2. 检查JtaTransactional的rollbackFor属性或确认抛出的是RuntimeException。3. 确保业务方法内部不“吞掉”异常。4. 检查finally块中是否有commit这会导致异常后仍然提交。连接泄露1. 编程式事务中未正确释放连接未用DataSourceUtils.releaseConnection。2. 事务传播行为如REQUIRES_NEW挂起/恢复逻辑有bug导致连接未归还。3. 事务同步回调中发生异常中断了正常的连接清理流程。1. 使用连接池的监控功能如HikariCP的JMX观察活跃连接数是否持续增长。2. 确保所有获取连接的路径都有配对的释放操作并放在finally块中。3. 审查挂起/恢复的代码确保ThreadLocal的清理无误。4. 为事务同步回调添加异常捕获避免影响主流程。死锁1. 多个事务以不同顺序访问和更新相同的数据库行/表。2.REQUIRES_NEW导致同一线程持有多个数据库连接如果操作相同资源极易在数据库层面死锁。1. 分析数据库死锁日志统一应用内的数据访问顺序。2. 谨慎使用REQUIRES_NEW评估是否可用NESTED保存点替代。3. 缩短事务持有时间尽快提交释放锁。嵌套事务NESTED不生效1. 底层数据库驱动不支持保存点Savepoint。2. 使用的MySQL存储引擎是MyISAM不支持事务。3. 在嵌套事务内部进行了DDL操作某些数据库会隐式提交。1. 确认数据库和驱动版本。MySQL InnoDB支持保存点。2. 确保表引擎为InnoDB。3. 避免在事务内执行CREATE,ALTER,DROP等语句。6.2 性能调优要点连接池配置事务管理器本身不管理连接池它依赖于你提供的数据源。因此连接池如HikariCP的配置至关重要。maximumPoolSize应根据应用并发量和数据库负载设置过小会导致等待过大会耗尽数据库资源。connectionTimeout应设置合理避免线程长时间等待获取连接。事务范围最小化Transactional注解应只加在真正需要事务的方法上并且方法内不应包含远程调用、文件IO、长时间计算等非数据库操作。这些操作会拉长事务持有连接的时间增加锁竞争和死锁风险也容易导致连接池连接被占满。只读事务优化对于查询方法务必设置JtaTransactional(readOnly true)。这会给底层数据库一个提示数据库可能会对此进行优化如启用读副本、使用更轻量级的锁机制。在我们的实现中也可以在事务完成后将只读连接标记为更安全的状态再归还给连接池。避免过度使用REQUIRES_NEW每次创建新事务都可能意味着从连接池获取一个新连接。在高并发下频繁使用REQUIRES_NEW会迅速耗尽连接池导致性能骤降。务必评估其必要性。监控与日志为TransactionManager和TransactionInterceptor添加DEBUG或TRACE级别的日志记录事务的创建、提交、回滚、挂起、恢复等关键事件。这在排查复杂的事务流问题时是无价之宝。可以设计一个TransactionListener接口方便地接入你的监控系统。6.3 调试技巧追踪事务边界当事务行为不符合预期时一个简单的调试方法是在关键位置打印线程和连接信息。// 可以写一个工具方法或放在拦截器里 public static void traceTransaction(String point) { Transaction tx TransactionSynchronizationManager.getCurrentTransaction(); Connection conn DataSourceUtils.getConnectionIfAvailable(dataSource); System.out.printf([%s] Thread: %s, Transaction: %s, ConnectionHash: %s%n, point, Thread.currentThread().getName(), tx ! null ? tx.getName() : null, conn ! null ? System.identityHashCode(conn) : null); }在方法入口、出口、以及调用其他服务的方法前后调用此跟踪方法可以清晰地看到事务是如何在调用链中传播、连接是如何被绑定和切换的。这比单纯看日志要直观得多。7. 总结与演进思考从头构建一个轻量级事务管理器就像亲手搭建了一座桥梁的骨架。ckanner/jta这样的项目其价值不在于替代Spring这样成熟的框架而在于提供一种理解事务管理底层原理的绝佳途径并为一个特定场景轻量、非Spring、嵌入式提供了可行的解决方案。在实现过程中每一个细节——从ThreadLocal的绑定与清理到传播行为的语义实现再到异常回滚的精细控制——都加深了对“事务”这一核心概念的理解。在实际使用中我个人体会最深的是对连接生命周期的敬畏。事务管理器的核心职责之一就是确保连接“从哪里来回哪里去”任何疏忽都可能导致连接泄露这在生产环境是致命的。因此在编写相关代码时try-finally块和资源清理逻辑必须像条件反射一样严谨。这个项目后续还可以向几个方向演进一是探索与响应式编程如Project Reactor的结合提供响应式事务管理原语二是提供更友好的Spring Boot自动配置Starter让它在Spring环境中也能作为轻量级选项被方便地引入三是加强对更多非JDBC资源如MongoDB、Redis的事务同步支持虽然它们可能不是严格的事务性资源但通过同步回调机制也能实现一定程度的“尽力而为”的协调。最终无论是使用成熟的框架还是自研轻量级组件理解其背后的原理和权衡才能让我们在复杂的系统设计中做出更合适的选择。ckanner/jta更像是一个教学案例和工具原型它剥开了事务管理这枚硬币的外壳让我们看到了里面精巧的齿轮是如何啮合运转的。