一段代码，获取锁之前记录系统时间（精确到纳秒），然后进行一些操作，再记录一下系统时间，这段代码会有多线程竞争。对比不同线程记录的结果，发现有时候会出现前一个时间较小，后一个时间却较大的情况，这是正常的吗？出现这种情况时前一个时间差在几十到一百多纳秒，后一个时间差是微秒级别
2个线程竞争锁，在获取锁之前记录系统时间，先获得锁的线程记录的时间一定更小吗？
- 写回答
- 好问题 0 提建议
- 追加酬金
- 关注问题
分享- 邀请回答
-
1条回答 默认 最新
关注这种情况是正常的，这种锁叫竞争锁，我是搞Java编程的，Java中就有竞争锁和公平锁，竞争锁的话资源不一定被哪一个等待的线程获取到，公平锁的话就是先来后到原则，等待时间最长的最先获取资源
解决 无用评论 打赏举报 分享
- 2018-09-27 03:17回答 1 已采纳 线程调用start()之后并不是立刻开始执行run方法。他需要等待其他系统资源准备就绪。例如：CPU。 Thread0最开始可能没有获取到CPU时间，Thread1却获取到且跑了几次。
- 2020-11-11 02:21回答 2 已采纳 代码没问题，只不过一直被同一个代码抢占，这是正常现象。
- 2021-02-19 14:21回答 6 已采纳 这个就是ReentrantLock的特性呀 默认是非公平的 第一次获取锁的对象 第二次获取的概率比较大。 你多执行几次 或者改成公平锁。 或者让出时间片Thread.yield();
- 2019-08-19 22:21婷小花的博客 最近在回顾线程中锁的内容，看到哟盼文章总结的很精简易懂，转载给大家看看。 本文链接：https://blog.csdn.net/lkforce/article/details/81128115 目录 一，对象头 1，Mark Word 2，指向类的指针 3，数组长度 二，...
- 2021-12-27 16:15回答 3 已采纳 这就是锁的价值啊。当多线程访问同一对象时，锁使得该对象在某一时刻只能被某一个线程访问，因为一个票不能同时分配给2个以上的人。你看到的结果是类似于单线程的效果，但是仍然是多线程。只是加锁以后，对票数这个
- 2018-03-18 15:16回答 3 已采纳 The compiler may not reorder the assignment and close statement, so you do not need a mutex if cal
- 2021-12-10 18:24回答 1 已采纳 对结果的写入进行上锁
- 2019-08-20 08:40农村闲置劳动力进城搬砖大队--三队长的博客 Synchronized关键字被加到方法上或者代码块上，在JVM规范中可以看到Synchonized在JVM里的实现原理:JVM基于进入和退出Monitor（监视器锁）对象来实现方法同步和代码块同步，但两者的实现细节不一样。代码块同步是使用...
- 2017-08-21 03:06回答 5 已采纳 【1】countWorker.sum++; ，sum不是局部变量吧？？。。。对象属性并非线程私有（线程中只存在引用），，对象内容存在堆中（这应当时题主说的共享内存） 按理说，，每次访问属性都应当去
- 2017-04-25 10:22回答 6 已采纳 package com.huadian.bean; public class Threads implements Runnable{ private Integer i=5; p
- 2022-01-24 14:12回答 2 已采纳 这个 synchronized 不是给读写加锁，而是给获取读写锁前的操作加锁，获取到后 synchronized 就已经释放了，读写本身是没有锁的
- 2023-10-06 14:42去北极避暑~的博客 或者，不加 volatile ，给循环里加个 sleep 也行,原因是加了sleep之后，while循环的执行速度变慢了，这样load操作的开销就不大了。为了解决这个变慢问题，提高效率，此时编译器就可能会对代码做出优化，即把一些本来...
- 2021-06-27 16:43回答 1 已采纳 线程的运行是不确保运行顺序的，所以出现的顺序是随机的。
- 2021-04-16 00:19徐同学呀的博客 `firstReader`表示第一个获取读锁的线程，若当前线程等于`firstReader`，读锁重入时`firstReaderHoldCount+1`，而非首个获取读锁的线程则用一个继承了`ThreadLocal`的内部类`ThreadLocalHoldCounter`给每个线程计数...
- 2021-03-05 18:57不知诶的博客 1.公平锁 / 非公平锁2.可重入锁 / 不可重入锁3....非公平锁非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。对于...
- 没有解决我的问题, 去提问
