12月9日(水)1コマ目

今日、やったこと

• スレッドの確認テスト
• セッション、セッションハイジャック

今日の確認テスト

スレッドセーフとは「マルチスレッド環境で複数スレッドで同時に実行されても問題ない」です。

変数に注目すると

• ローカル変数はメソッド呼び出し毎にスタック上にエリアを確保するため、問題なし。
• フィールドはインスタンス生成時にヒープ領域にエリアを確保するため、同じインスタンスから生成したスレッド間では共有する。よって、スレッドセーフではない。
• クラス変数はクラスロード時にエリアを確保するため、全インスタンスでエリアを共有する。よって、スレッドセーフではない。

です。

問１

ソースコードは以下です。

１インスタンスから２つスレッドを生成しています。よって、フィールドvalを共有することになります。

問２

ソースコードは以下です。

1インスタンスから２つスレッドを生成しています。が、ローカル変数だけなので、スレッドセーフではない変数はありません。

問３

ソースコードは以下です。

1インスタンスから２つスレッドを生成しています。

クラス変数diffをスレッド間で共有することなります。が、finalがついているため、実質定数です。（初期値２が代入された後は変更不可能）

よって、diffはスレッドセーフかどうかを考える必要はないです。

今日のホワイトボード

まず、セッションとは

Webアプリケーション等で利用者が目的を達成するために利用者(クライアント)とサーバー間の一連のやり取りで１つのセッション。データベースのトランザクションと同じような感じ。

図　そもそもセッションとは

Webでセッションを

1セッションにはクライアントとサーバー間で複数回のやり取りが行われる。

が、WebのプロトコルHTTPは1往復のやり取りで完結。複数回のやり取りでデータを共有する仕組みもない。

図　Webは(HTTPは）

セッションオブジェクトとは

HTTPにはない同じクライアントと複数回のやり取りでデータ共有できる仕組みをアプリケーションサーバー側で用意した。これがセッションオブジェクト。

図　セッションオブジェクトとは

クライアントとセッションオブジェクトを紐づける

クライアントとサーバー中のセッションオブジェクトが同じセッションIDを持つことで1対1に対応できるようにしてある。

図　セッションIDでクライアントとセッションオブジェクトを紐づける

クライアント側はセッションIDをCookie（クッキー）に保存する。

セッションハイジャック

セッションIDはクライアント<=>サーバー間でネットワーク経由でやり取りされるため簡単に盗聴可能。

WebブラウザのCookieも簡単に変更ができるため、サーバー中の他人のセッションオブジェクトを簡単に盗むことができる。

図　セッションハイジャック

セッションハイジャックの対応策は暗号化です。