問題タブ [atomicinteger]

と の間にパフォーマンスの違いはAtomicIntegerありIntegerますか?

this.count をローカル変数に割り当てる理由と、ローカル変数が final として宣言された理由を説明できる人はいますか?

私は AtomicInteger をググったところ、メモリ シーケンサーに AtomicInteger(AtomicLong) を使用できると誰かが言っているのを見ました ( http://www.cs.hut.fi/u/tlilja/multicore/slides/java_multicore.pdf )。これが私のテストです：

このコードを何度も実行した後、アトミック出力の合計が 1000 でない場合があることがわかりました。これは、 getAndIncrementメソッドの重複した戻り値があることを意味します。

誰でも理由を説明できますか？ありがとう。

*注: 実行中の機能。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 41 43 47 24 49 5 52 50 53 55 54 58 56 57 59 60 61 62 63 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 87 88 89 90 91 91 92 93 94 95 96 103 106 102 109 100 101 108 107 111 105 112 114 110 117 117 116 119 115 120 113 118 121 122 126 125 124 123 127 128 130 131 129 132 133 135 136 137 138 139 140 141 142 144 145 146 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 189 201 202 203 204 205 206 207 208 208 209 210 211 212 213 213 214 216 217 219 218 220 232 231 231 231 231 231 231 231 228 227 226 225 224 223 221 222 233 234 235 237 237 239 236 236 238 241 243 243 243242 245 244 246 247 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 274 276 277 278 278 281 281 282 285 284 284 283 288 287 287 292 292 292 292 291 293 294 290 295 296 297 298 299 300 301 302 302 303 304 305 306 307 308 309 310 311 312 313 313 314 315 316 317 318 320 321 319 322 323 324 325 326 327 328 330 344 345 346 347 348 342 349 350 351 352 353 354 355 356 357 358 359 360 361 362 366 365 364 368 369 370 370 371 372 373 375 374 391 397 390 399 398 400 396 393 403 404 402 402 406 405 407 408 409 410 411 412 412 413 414 415 416 417 417 418 420 421 423 422 424 425 426 438 458 459 460 457 456 462 463 464 455 454 453 470 452 473475 451 450 477 479 480 449 482 448 44444442509443441 511 510 508 507 506 515 516 518 519 520 50505 504 522 503 503 525 532 501 500 499 548 549 487 486 485 485 484 550 552 483 481 478 556 557 476 558 474 472 471 469 468 567 467 569 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 711 710 709 708 728 729 707 731 732 733 682 681 679 678 671 670 734 735 727 739 726 725 724 738 740 742 737 744 745 736 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 830 831 832 839 840 842 843 844 846 847 848 849 850 851 853 855 804 856 854 852 858 848 860 861 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 949 920 919 918 915 916 917 951 950 947 946 943 941 937 936 935 952 953 933 930 954 955 956 957 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 と、その操作がアトミックである方法と、これらのプロパティがマルチスレッドにどのように役立つかについて読んでいました。

同じことをテストするために、次のプログラムを作成しました。

各スレッドは 500 回ループし、スレッドが getNext() を呼び出すたびに一意の番号を取得する必要があるため、セットの最終的なサイズは 1000 になるはずです。

しかし、出力は常に 1000 未満です。ここで何が欠けていますか?

}

私は次のことをしようとしています:

1. AtomicInteger私のプログラムは、 fromをインクリメントし、 newを にConcurrentHashMap<String, AtomicInteger>追加するスレッドを開始します。その場合、 のサイズはの値と等しくなります (もちろん、同じキーを持つエントリの場合)。IntegerConcurrentHashMap<String, CopyOnWriteArrayList<Integer>>CopyOnWriteArrayListAtomicInteger
2. すべてのスレッドが完了した後 (が終了したとき) 、そのマップを値でソートするためにCountDownLatch変換しようとします。比較できないためです。ConcurrentHashMap<String, AtomicInteger>HashMap<String, Integer>AtomicInteger
3. 変換後、値で並べ替え、HashMap値が最も高い 20 エントリを選択します。並べ替えられたマップでは、それらは最初の 20 エントリです。
4. 最後に、値をリストにパックし、GSON で JSON 文字列を作成します。

問題

私が期待すること: の使用により、AtomicInteger同じ キーを持つすべてのエントリのすべてのサイズと値が、次のような JSON 文字列であっても等しいと予想されます。ConcurrentHashMapCopyOnWriteArrayList

しかし結果は違うようです。値をテストするためにいくつかのコンソール出力を作成したところ、次の結果が得られました。

ConcurrentHashMapからにコピーしている間HashMap、値を再度確認します。「不正にコピーされた」値が異なるたびに (コード スニペットについては、以下を参照してください):

その後、新しいものをさらに 4 回繰り返しHashMapて値を再度比較し、新しいランダムな「不適切なコピー」値を取得するたびに (コピー中に値が検出されなかったことに注意してください) (以下のコード スニペットを参照してください)。

私のJsonも間違っています。"CGCCACC"たとえば、Json の配列のキーサイズは であり887、上記の表 ( 849) とは異なります。

私が使用するコード スニペットは次のとおりです(一部は StackOverflow からのものです)。

スレッドに新しい整数をインクリメントAtomicIntegerして追加する:CopyOnWriteArrayList

ConcurrentHashMap<String, AtomicInteger>から各値にコピーしHashMap<String, Integer>（非常に非効率的だと思います）、すぐに検証します：

コピーされた値を再度確認しますmyHashMap(ここでは、ランダムな「不適切なコピー」値も取得します):

なぜそれが起こるのか、私の論理で何かを見逃したのでしょうか?

詳細情報/コードなどについては、お問い合わせください。

助けてくれてありがとう！

私のターゲット システムには、C++0x をサポートする g++ 4.6.3 があります (C++11 はサポートしません)。2 つのスレッド間でアクセスする状態変数を格納するために、atomic_int を使用しています。ただし、この型に対して定義された不等号演算子はないようです。atomic_int を比較するにはどうすればよいですか?

次のようなシナリオがあります。懸念事項を明確にするためにここで示しているのは、単純な形式のコードです。

でできることは知っていますが、int[]ちょっと奇妙に見えます。このような場合、AtomicInteger は Mutable Integer の代わりになるのでしょうか? いいえの場合、なぜですか?

いくつかのことを行い、カウンターなどのいくつかのメトリックを更新する単一のライタースレッドを持つアプリケーションがあります。アプリケーションには、統計を読み取ってそれらを処理する他のスレッドが多数あります。メトリックが最新であることは必須ではありませんが、ライター スレッドがブロックされる時間をできるだけ短くする必要があります。私は、次のうちどれが私のニーズに適しているか疑問に思っていました。

オプション 1 - ライターのみが更新できる非アトミック フィールドと、以下を使用して設定される AtomicXXX フィールドがありますlazySet。

オプション 2 - 経由で更新される AtomicXXX フィールドがあるだけですaddAndGet。

それとも、何か他のことをしたほうがいいでしょうか？

前もって感謝します。

ロックと基本的なマルチスレッドの概念についてはかなり理解していたと思いますが、ここで何かをめちゃくちゃにしています。

プログラムは、テキスト ファイルのファイル名と使用するスレッドの数をユーザーから受け取り、そのファイル内の "http" リンクの数を数えてから、その数をユーザーに返すだけです。

ただし、私の人生では、スレッドを適切にカウントすることはできません。「count」変数をアトミック整数にして、「incrementAndGet()」関数を使用してみました。コード内のロックがあるべきだと思った場所にロックを配置してみました。また、必要な関数を同期するように指定してみました。 、すべて無駄に。

私はロック、同時実行性などについてできる限りのことを読んできましたが、どうやら非常に間違ったことをしているようです。コードのどこに/なぜロックを配置する必要があるのか​​ （または、アトミック整数を適切に使用する方法がより効果的である場合）、誰かが私に説明できますか？

私はもともと "count" 変数が使用されたとき (ループの外側で実際に何かを実行したとき) にロックしていましたが、プログラムを実行するとあらゆる種類の数値を受け取ります。

私のコードは次のようになります。

適切な場所でロックを使用する必要があるよりも大きな問題がここで発生している場合は、私に知らせてください.適切にロックされていますが、それらがどのように正しく機能するかを理解していないか、間違った場所に置いているだけです。

java.util.concurrent パッケージの API ドキュメントを読みましたが、明らかに誤解しているものがあります。概要は言う

単一変数でのロックフリー スレッドセーフ プログラミングをサポートするクラスの小さなツールキット。

ただし、小さなテスト アプリケーションでは、少なくともスレッド間で共有されている場合、AtomicInteger クラスがスレッド セーフを提供しないことが示されています ( getAndSet / increment メソッド自体が少なくともアトミックであることは認めます) 。

テスト：

このクラスを実行すると、常に 950 から 1000 の範囲の結果が得られますが、常に正確に 1000 が表示されると予想されます。

2 つのスレッドがこの共有 AtomicInteger 変数にアクセスすると、一貫した結果が得られない理由を説明できますか? スレッドセーフ保証を誤解していませんか?