AtomicInteger真的产生原子整数吗?

时间:2014-01-02 20:22:56

标签: java thread-safety sequences atomicinteger

我用Google搜索了AtomicInteger,我看到有人说我们可以使用AtomicInteger(AtomicLong)作为内存序列器(http://www.cs.hut.fi/u/tlilja/multicore/slides/java_multicore.pdf)。这是我的测试:

public class TestAtomicInteger {

public static void main(String[] args) {

    final AtomicInteger sequencer = new AtomicInteger(1);
    final Set<Integer> integers = new HashSet<>();
    //final Set<Integer> integers = new ConcurrentSkipListSet<>();


    final Runnable task = new Runnable() {

        @Override
        public void run() {
            int next = sequencer.getAndIncrement();
            integers.add(next);
            System.out.println(integers.size());
        }
    };
    for (int i = 0; i < 1000; i++) {
        Thread t = new Thread(task);
        t.start();
    }
}
}

多次运行此代码后,我发现有时原子输出总数不是1000.这意味着 DUPLICATE 返回 getAndIncrement 方法。

有人解释原因吗?感谢。

* 注意:在运行功能中。如果我使用System.out.println(下一个);有时我也会看到一些丢失的音序器。 *

SAMPLE OUTPUT 1:

1 6 8 五 2 10 3 4 12 11 9 14 15 7 13 16 17 18 19 20 21 22 23 24 25 26 27 28 29 三十 31 32 33 34 35 36 37 38 39 40 42 41 43 45 44 47 49 46 48 52 52 50 53 55 54 58 56 57 59 60 61 62 63 64 65 67 68 69 66 70 71 72 73 74 75 76 77 78 80 81 79 82 83 84 85 86 87 88 89 90 91 92 93 94 95 97 96 98 99 104 103 106 102 109 100 101 108 107 111 105 112 114 110 117 116 119 115 120 113 118 121 122 126 125 124 123 127 128 130 131 129 132 133 134 135 136 137 138 139 140 141 142 144 145 143 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 170 169 171 172 173 174 175 176 177 178 179 180 181 182 186 188 189 185 190 184 191 192 183 187 193 194 196 197 198 199 195 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 216 217 219 215 218 220 232 231 230 229 228 227 226 225 224 223 221 222 233 234 235 237 239 240 236 238 241 243 242 245 244 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 285 284 283 289 288 287 286 292 291 293 294 290 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 320 321 319 322 323 324 325 326 327 328 330 329 331 332 333 334 335 337 336 338 339 340 341 343 344 345 346 347 348 342 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 366 365 364 368 367 369 370 371 372 373 375 374 379 378 377 376 380 381 382 383 384 385 386 389 388 387 392 394 395 391 397 390 399 398 400 396 393 403 404 402 401 406 405 407 408 409 410 411 412 413 414 415 416 417 419 418 420 421 423 422 424 425 426 427 429 430 428 434 433 435 432 431 436 437 440 439 445 446 447 438 458 459 460 457 456 462 463 464 455 454 453 470 452 473 475 451 450 477 479 480 449 482 448 444 442 509 443 441 511 510 508 507 506 515 516 518 519 520 505 504 522 503 502 525 532 501 500 499 498 497 496 495 535 494 493 538 492 491 490 541 543 489 546 488 548 549 487 486 485 484 550 552 483 481 478 556 557 476 558 474 472 471 469 468 567 467 569 570 466 465 461 574 573 575 576 572 571 568 566 565 564 563 562 561 560 559 555 554 553 551 547 545 544 540 578 585 542 539 537 536 595 534 597 533 531 599 530 529 528 600 602 527 526 604 524 523 521 608 519 517 514 513 614 512 613 612 616 617 611 610 619 609 621 607 606 622 623 605 603 601 598 625 627 596 594 631 593 592 632 633 591 590 638 589 588 587 640 641 586 584 583 582 648 651 653 655 657 581 658 659 662 664 580 668 579 669 577 667 666 672 665 673 674 675 663 661 676 677 680 683 685 687 689 661 660 656 654 692 652 650 649 646 647 703 645 644 643 642 639 637 636 635 634 630 713 629 628 626 715 624 717 620 720 722 618 615 721 723 719 718 716 714 712 711 710 709 708 728 729 707 706 705 704 702 701 700 699 698 697 696 695 694 693 691 690 688 686 684 730 731 732 733 682 681 679 678 671 670 734 735 727 739 726 725 724 738 740 742 737 744 745 736 746 747 743 741 749 748 751 750 753 752 754 755 756 757 758 759 760 761 762 763 765 764 770 771 772 773 774 769 768 776 767 780 766 779 778 777 775 784 783 782 781 787 788 790 791 792 796 786 798 799 800 785 803 805 807 802 801 797 795 794 793 812 789 813 811 816 810 809 808 806 819 821 823 824 826 827 828 830 831 832 839 840 842 843 844 846 847 848 849 850 851 853 855 804 856 854 852 858 848 860 861 845 841 838 837 836 835 834 864 865 833 829 825 822 868 869 820 818 871 817 874 875 815 814 876 877 878 879 880 881 882 883 885 887 888 889 891 892 894 896 898 901 902 903 905 906 875 873 872 870 867 866 863 862 859 857 904 900 899 897 895 893 907 890 908 886 884 909 910 911 912 913 914 927 928 926 929 931 932 934 938 939 940 942 925 944 945 924 923 922 948 921 949 920 919 918 915 916 917 951 950 947 946 943 941 937 936 935 952 953 933 930 954 955 956 957 958 959 960 961 962 963 964 965 966 968 969 970 971 972 985 986 987 967 989 988 990 985 984 991 983 982 993 981 980 979 978 977 976 975 974 973 995 995 992

6 个答案:

答案 0 :(得分:3)

您的代码的一个主要问题是您将数字添加到非线程安全的HashSet。这就是你观察的原因。如果您使用了线程安全集合,那么您将获得预期的结果:

final Set<Integer> integers = new ConcurrentSkipListSet<>();

但这引入了额外的同步层。另一种方法是使用普通数组int[] numbers = new int[1000];并使用:numbers[next-1]++;计算出现次数。

新参考代码:

public static void main(String[] args) throws Exception {

    final AtomicInteger sequencer = new AtomicInteger(1);
    final int[] integers = new int[1000];

    final Runnable task = new Runnable() {

        @Override
        public void run() {
            int next = sequencer.getAndIncrement();
            integers[next-1]++;
        }
    };
    List<Thread> threads = new ArrayList<>();
    for (int i = 0; i < 1000; i++) {
        Thread t = new Thread(task);
        t.start();
        threads.add(t);
    }
    for (Thread t : threads) {
        t.join();
    }
    for (int i = 0; i < 1000; i++) {
        if (integers[i] != 1) System.out.println(i + " -> " + integers[i]);
    }
}

答案 1 :(得分:2)

如果我在计算机上运行程序,我会在10次内观察到不正确的输出。 (这与Netbeans 7中的控制台模拟器有关。)

但是,如果我在所有线程完成后修改它以检查集合的大小,它总是包含1,000个唯一的整数。即使各个线程在运行时生成的输出存在错误,也是如此。 (也就是说,在线程打印的行中,打印了重复项,但执行完成后集合的真实大小实际为1,000)

因此我得出结论,问题是你的平台为System.out提供的所有写入PrintStream的1,000个线程都在破坏输出。在我的平台上,我可以在执行期间看到损坏的输出,但最后在集合中总是有1,000个唯一的整数。

public static void main(String[] args) throws InterruptedException {

    final AtomicInteger sequencer = new AtomicInteger(1);
    final Set<Integer> integers = new ConcurrentSkipListSet<Integer>();

    final Runnable task = new Runnable() {

        @Override
        public void run() {
            int next = sequencer.getAndIncrement();
            integers.add(next);
            System.out.println(next);
        }
    };
    List<Thread> threads = new ArrayList<Thread>(1000);
    for (int i = 0; i < 1000; i++) {
        Thread t = new Thread(task);
        t.start();
        threads.add(t);
    }

    for (Thread t : threads) {
        t.join();
    }
    System.out.println(integers.size());
}

答案 2 :(得分:1)

AtomicInteger调用Unsafe类,然后调用本机调用。所以是AtomicInteger理论上可以返回非原子更新。这取决于JVM及其运行的底层架构。

但是考虑到线程的性质,我总是认为错误在我的代码中而不是JVM。

我运行此代码但无法检测到任何碰撞。 JDK 1_7_45获胜7

  public static void main(String[] args) {

      final AtomicInteger sequencer = new AtomicInteger(1);
      final Set<Integer> integers = new HashSet<Integer>();

      final Runnable task = new Runnable() {

          @Override
          public void run() {
              int next = sequencer.getAndIncrement();
              synchronized (integers){
                  if(integers.contains(next)){
                      System.out.println("duplicate detected " + next);
                  }
                  integers.add(next);
              }
          }
      };


      for(int j = 0; j < 1000; j++){
          System.out.print("testing " + j +" ");
          sequencer.set(0);
          integers.clear();
          List<Thread> threads = new ArrayList<Thread>(10000);
          for (int i = 0; i < 1000; i++) {
              Thread t = new Thread(task);
              threads.add(t);
              t.start();
          }
          for (Thread t : threads) {
              try {
                  t.join();
              } catch (InterruptedException e) {
                  e.printStackTrace();
              }
          }
          System.out.println("integers size " + integers.size());
      }
  }

答案 3 :(得分:0)

正如其他人所说:

  1. 使用Thread.join()等待所有线程在循环结束时完成。对所有线程的引用必须已存储在课程集合
  2. 在退出前关闭()STDOUT
  3. 围绕该计划:

    1. 通过sort和/或wc -l
    2. 管道输出
    3. 使用diff检查由简单循环创建的数字列表
    4. 如果差异发现差异则退出警告
    5. 在脚本循环中重复10'000次。

      报告回来。

答案 4 :(得分:0)

更新的输出包含7次打印两次。

(接受你的输出| sort | uniq --count | sort)

在末尾打印出来(第一个col是看到的次数,第二个col是值)

  1 991
  1 992
  1 993
  2 519
  2 52
  2 661
  2 848
  2 875
  2 985
  2 995

这是因为您正在打印非线程安全的HashSet的大小,因此有时大小不会显示更新的值。

更改为线程安全集实现应该有效。

答案 5 :(得分:0)

对我来说,这是因为ConcurrentSkipListSet.size()。虽然线程安全,但这种弱一致的集合在迭代或计数方面并不精确。

来自ConcurrentSkipListSet.size()的Javadoc

  

请注意,与大多数集合不同,size方法不是常量操作。由于这些集的异步性质,确定当前元素数需要遍历元素。此外,批量操作addAll,removeAll,retainAll和containsAll不保证以原子方式执行。例如,与addAll操作同时运行的迭代器可能只查看一些添加的元素。

相关问题