在DataWorks中执行实时同步时，是否使用锁机制实际上取决于多种因素，包括但不限于数据源类型、目标存储类型、同步策略以及所使用的具体同步工具或组件。以下是一些更具体的分析：
1. 数据源类型：
- 如果数据源是关系型数据库（如MySQL、Oracle等），那么同步过程中可能会涉及到对表的读取操作。某些数据库支持无锁读取（如使用快照隔离或读已提交隔离级别），而有些情况下可能需要加锁以确保数据的一致性。
- 如果数据源是NoSQL数据库或流数据（如Kafka），它们通常有自己的数据一致性和并发控制机制，这也会影响同步过程中的锁定行为。
2. 目标存储类型：
- 目标存储可能是关系型数据库、NoSQL数据库、OSS或其他存储服务。每种存储服务都有自己的写入机制和并发控制策略。例如，OSS本身没有传统意义上的锁机制，但写入操作可能是原子的。
- 对于关系型数据库，写入操作可能需要加锁来确保数据的完整性和一致性。
3. 同步策略：
- 实时同步可能意味着数据一旦在源端发生变化，就立即同步到目标端。这种高频率的同步可能需要更精细的并发控制。
- 另一方面，如果同步是定期批量进行的，那么锁定策略可能会有所不同，因为可以在同步期间对源数据进行锁定，以减少并发冲突。
4. 使用的同步工具或组件：
- DataWorks可能提供了多种同步组件或插件，用于连接不同的数据源和目标存储。这些组件可能有自己的锁定策略或配置选项。
- 此外，也可能使用了第三方的ETL工具或中间件来进行数据同步，这些工具通常会有自己的锁定和并发控制机制。
5. 业务需求和性能考虑：
- 在某些业务场景下，可能更倾向于无锁或低锁定的同步策略，以减少对业务的影响。
- 然而，如果数据的一致性和完整性是首要考虑的因素，那么可能会选择更严格的锁定策略。
- 同时，性能也是一个重要的考虑因素。频繁的锁定和解锁操作可能会影响同步的性能和吞吐量。
综上所述，要确定DataWorks实时同步过程中是否使用锁以及使用何种类型的锁，需要综合考虑上述因素。建议查阅DataWorks的官方文档、相关数据库和存储服务的文档，以及具体的同步组件或工具的文档，以获取更详细和准确的信息。此外，如果可能的话，进行实际的测试和验证也是一个好方法。