我知道sync是在多个进程之间，而不是多个线程之间。在Linux上，设置存储在一个文件中，所以你需要原子地写入它。QSaveFile为你做到了这一点。在Windows上，写入注册表项本身就已经是线程安全的，但是写入大量的项可能需要进一步的锁定。
Looking at the source code在我看来，Qt总是试图以原子方式写入。只是根据文件系统的不同，如果锁文件不起作用，这可能会失败。如果setAtomicSyncRequired为false，则写入设置将继续而不具有原子性，否则写入设置将失败。请参阅链接文件中的第1373行：

void QConfFileSettingsPrivate::syncConfFile(QConfFile *confFile)
{
…
    /*
        Use a lockfile in order to protect us against other QSettings instances
        trying to write the same settings at the same time.

        We only need to lock if we are actually writing as only concurrent writes are a problem.
        Concurrent read and write are not a problem because the writing operation is atomic.
    */
    QLockFile lockFile(lockFileName);
    if (!readOnly && !lockFile.lock() && atomicSyncOnly) {
        setStatus(QSettings::AccessError);
        return;
    }
…
}

字符串
QSettings本身由每个ini文件的互斥锁和一个全局互斥锁保护。我认为假设所有操作都是线程安全的是安全的。这符合我对Qt的期望。sync只需要将数据发布到其他进程，而不是同一进程中的其他线程。
当我开始使用helgrind和thread sanitizer时，它们会给我带来数据竞争问题，因为不同的线程写同一个文件。被同步访问的文件是存储QSettings设置的配置的文件。
问：这是假阳性吗？
是的，我假设这是误报。杀毒程序可能不理解锁定文件和配置文件之间的关系。
问：我使用Qsettings时有什么问题吗？如何改进它以获得一种方法来存储应用程序中所有线程的公共设置？
我不认为有什么问题。但是，要注意原子性。加载和保存单个设置是原子的，但访问一组设置不是。例如，如果一个线程更改了两个设置，而另一个线程读取这两个设置，则阅读线程可能会获得一个旧值和一个新值。
问：如果只有一个指向同一个QSetting对象的指针，并设置为true setAtomicSyncRequired，以便通过sync（）每隔一小段时间同步所有线程设置，这会是一个好主意吗？
不，我不认为这是一个好主意，如果有的话，它更糟糕。像QSettings::beginGroup，endGroup，beginArray和endArray这样的操作将无法正常工作，除非你添加一些外部锁定。
这种设计是为了让QSettings对象本身是线程或父对象的本地对象，并且可能是短暂的。
至于同步，请注意isAtomicSyncRequired默认为true，sync()由QSettings析构函数自动调用。