GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — 获取accessToken先加锁,会导致后续的请求需要很长时间才能拿到锁 · Issue #1582 · binarywang/WxJava

获取accessToken先加锁,会导致后续的请求需要很长时间才能拿到锁 #1582

New issue
Copy link
New issue
Copy link
Closed
Closed
获取accessToken先加锁,会导致后续的请求需要很长时间才能拿到锁#1582
Copy link

Description

@Wismyluckstar
Wismyluckstar
opened on May 25, 2020
Issue body actions

image

Activity

  1. lkqm commented on May 31, 2020

    @lkqm
    lkqm
    on May 31, 2020
    More actions

    目前确实会存在这样的问题, 后续使用lock.tryLock修复这个问题

  2. lkqm
    added a commit that references this issue on May 31, 2020

    Fix binarywang#1582 use lock.tryLock() avoid waiting for locks for a …

    This issue will close once commit 829b103 is merged into the 'master' branch.
    829b103
  3. binarywang
    added a commit that references this issue on May 31, 2020

    🐛 #1582 use lock.tryLock() to avoid waiting for locks for a long time

    6c3d090
  4. binarywang commented on Jul 19, 2020

    @binarywang
    binarywang
    on Jul 19, 2020
    Owner
    More actions

    已修复

  5. binarywang
    closed this as completedon Jul 19, 2020
  6. cookier commented on Sep 16, 2020

    @cookier
    cookier
    on Sep 16, 2020
    More actions

    请问一下把lock改成tryLock有什么提升吗?
    因为我看这里tryLock也是通过不断循环,判断是否锁住,跟lock直接锁住好像效果一样?

  7. lkqm commented on Sep 16, 2020

    @lkqm
    lkqm
    on Sep 16, 2020
    More actions

    如果用lock这里有上万个请求会导致最后一个请求会等待前面9999个人的时间。而实际上只希望请求tencent获取accessToen只有一个线程,而使用tryLock会在某个线程更新accessToken后,其余线程只需要短暂等待后即可获取有效的accessToekn.

  8. cookier commented on Sep 17, 2020

    @cookier
    cookier
    on Sep 17, 2020
    More actions

    在做测试之前,看你的说明后我理解是lock为单纯阻塞,并发线程都在干等着;tryLock则保持了并发线程的灵活性,只需要短暂等待就能拿到结果。不过再仔细想,每个线程都要额外等多100毫秒,响应不是更慢吗?
    模拟并发测试后发现lock方式执行时间1000+。tryLock执行时间3000+,不知道我测试方式是否正确。

        private Lock lock = new ReentrantLock();
        static boolean flag = false;
        static long x = System.currentTimeMillis();
    
        @Test
        public void testLock() throws IOException {
            for (int i = 0; i < 1000; i++) {
                new Thread(() -> doSome()).start();
            }
            System.in.read();
        }
    
        public void doSome() {
            lock.lock();
            try {
                if (flag) {
                    return;
                }
                System.out.println(Thread.currentThread().getName() + "得到了锁" + DateUtil.format(new Date(), "yyyy-MM-dd HH:mm:ss:SSS"));
                //模拟耗时操作
                Thread.sleep(1000);
                flag = true;
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                lock.unlock();
                System.out.println(System.currentTimeMillis() - x);
            }
        }
    
        public void doSome2() {
            boolean locked = false;
            try {
                do {
                    locked = lock.tryLock(100,TimeUnit.MICROSECONDS);
                    if (flag) {
                        return;
                    }
                } while (!locked);
    
                System.out.println(Thread.currentThread().getName() + "得到了锁" + DateUtil.format(new Date(), "yyyy-MM-dd HH:mm:ss:SSS"));
                //模拟耗时操作
                Thread.sleep(1000);
                flag = true;
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                if (locked) {
                    lock.unlock();
                }
                System.out.println(System.currentTimeMillis() - x);
            }
        }
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.