问题标签 [atomicinteger]

AtomicInteger和之间有任何性能差异Integer吗？

谁能解释为什么我们将 this.count 分配给局部变量，以及为什么将局部变量声明为 final？

我搜索了 AtomicInteger，我看到有人说我们可以将 AtomicInteger(AtomicLong) 用于内存排序器（http://www.cs.hut.fi/u/tlilja/multicore/slides/java_multicore.pdf）。这是我的测试：

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

任何人解释为什么？谢谢。

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

样本输出 1：

1 6 8 5 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 30 31 32 33 34 35 36 37 38 39 40 42 474 43 46 48 4 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 151 152 153 154 155 156 157 158 159 160 161 162 162 163 163 164 164 165 166 166 167 167 167 168 168 168 169 169 172 172 173 173 174 174 175 175 176 177 177 177 177 177 178 179 179 179 180 181 182 182 182 186 186 189 189 189 189 185 185 185 185 184 184 184 184 199 192 193 192 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 195 199 195 195 195 195 195 195 2012 202 203 204 205 206 206 207 208 209 210 212 212 212 213 214 216 216 219 219 215 215 218 220 232 232 232 231 231 229 228 228 227 227 226 225 225 224 223 223 223 222 222 222 234 234 234 235 237 237 237 239 239 239 236 236 238 238 238 238 238 238 241 241 241 241 243 243242 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 473475 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 474 474 472 471 471 469 467 467 467 467 467 467 469 570 466 570 466 465 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 639637 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 777 775 775 784 783 782 782 781 787 787 788 790 790 791 791 792 796 796 798 798 798 799 800 785 803 803 805 805 807 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 901902 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 99280 979 978 977 976 975 974 973 995 995 99280 979 978 977 976 975 974 973 995 995 992

我正在阅读 AtomicInteger 以及它的操作如何是原子的以及这些属性如何使其对多线程有用。

我编写了以下程序来测试它。

我期望集合的最终大小应该是 1000，因为每个线程循环 500 次，并且假设每次线程调用 getNext() 它应该得到一个唯一的数字。

但是输出总是小于 1000。我在这里缺少什么？

}

我正在尝试执行以下操作：

1. 我的程序启动线程，增加一个AtomicIntegerfromConcurrentHashMap<String, AtomicInteger>并添加 new Integerto ConcurrentHashMap<String, CopyOnWriteArrayList<Integer>>。在这种情况下，的大小CopyOnWriteArrayList等于的值AtomicInteger（当然对于具有相同键的条目）
2. 在所有线程完成后（CountDownLatch完成后），我尝试转换ConcurrentHashMap<String, AtomicInteger>为HashMap<String, Integer>按值对 Map 进行排序，因为AtomicInteger不可比较。
3. 转换后，我HashMap按 Values 排序并选择 20 个具有最高值的条目 - 在排序后的 Map 中，它们是前 20 个条目。
4. 最后，我将值打包到一个列表中，并使用 GSON 制作 JSON 字符串。

问题

我的期望：由于我使用AtomicInteger,ConcurrentHashMap并且CopyOnWriteArrayList 我希望具有相同键的所有条目的所有大小和值都是相等的，即使在我的 JSON 字符串中，例如：

但结果似乎有所不同。我做了一些控制台输出来测试我的值并得到以下结果：

ConcurrentHashMap在从to复制时，HashMap我再次验证我的值。每次“错误复制”的值都不同（代码片段如下所示）：

之后，我在我的新值上再迭代 4 次HashMap以再次比较我的值，并且每次我得到新的随机“错误复制”值（注意，复制时未检测到值）（代码片段如下所示）：

我的 Json 也不正确。例如"CGCCACC"，我在 Json 中的数组的密钥大小是887，不像上表中的 ( 849)。

以下是我使用的代码片段（其中一些来自 StackOverflow）：

在我的线程中增加AtomicInteger和添加新整数：CopyOnWriteArrayList

复制 fromConcurrentHashMap<String, AtomicInteger>到HashMap<String, Integer>每个值（我猜它的效率很低）并立即验证：

再次验证复制的值myHashMap（这里我也得到随机的“错误复制”值）：

为什么会发生这种情况，我是否错过了逻辑中的某些内容？

有关更多信息/代码等 - 请询问。

感谢你们对我的帮助！

我的目标系统有支持 C++0x（但不支持 C++11）的 g++ 4.6.3。我正在使用 atomic_int 来存储我在两个线程之间访问的状态变量。但是，似乎没有为此类型定义不等于运算符。我如何比较 atomic_ints？

我发现在 Java 中使用AtomicIntegers,GetAndDecrement比GetAndIncrement. 为什么会这样？

我已经稍微提炼了这个问题，消除了我的一些理解，试图让它像 poss 一样简洁和具体，所以它可能看起来很基本

我应该如何使用 AtomicInteger 作为参考计数器来管理某些资源的清理但以安全和原子的方式？

例如：

1）香草示例：

这一切都很好， refCt 本身是原子的，但值可能会以关闭资源不会关闭的方式发生变化 - 例如，另一个线程在条件之前减少计数。

使用 var（线程中的堆栈）可以确保在我的线程中维护 refCt，我猜但是

2）矫枉过正（？）示例：

我的 refCt 本身是原子的，我对条件（在 AtomicInteger 外部）的测试与保障原子性同步。

3）我是否应该实际使用AtomicInteger自身来管理条件通过#compareAndSet并避免阻塞？

4）这一切是否比应有的复杂/我不能只见树木不见森林吗？

我有以下情况：我在这里展示的代码很简单，以澄清我的担忧：

我知道它可以做到，int[]但它看起来有点奇怪。在这种情况下，AtomicInteger 是 Mutable Integer 的良好替代品吗？如果否，那么为什么？

我有一个带有单个编写器线程的应用程序，它执行一些操作并更新一些指标，例如计数器等。该应用程序有许多其他线程，它们读取统计信息并使用它们做一些事情。指标是否是最新的并不重要，但编写器线程需要被阻塞的时间越短越好。我想知道以下哪个更适合我的需求：

选项 1 - 有一个只有作者可以更新的非原子字段，以及一个使用以下设置的 AtomicXXX 字段lazySet：

选项 2 - 只需有一个 AtomicXXX 字段，该字段通过以下方式更新addAndGet：

还是我做其他事情会更好？

提前致谢。