マルチスレッドにおけるMapオブジェクト - 半径5メートル
身近でjava.util.HashMapのインスタンスがスレッドセーフでない事に起因したトラブルの話があったので、実際にサンプルを作って試してみました。 まず各スレッドで動作するRunnableなworkerクラス。 import java.util.Map; public class Worker implements Runnable { private Map<String, String> targetMap; public void setMap(Map<String, String> targetMap) { this.targetMap = targetMap; } public void run() { String threadId = String.valueOf(Thread.currentThread().getId()); for (int i = 0; i <
java.net.URL#openStream()はclient timeoutしない - 半径5メートル
JavaのSocket周りでは割とよくある感じですが、以下のコードだとconnectもreadもデフォルトで無限に待ち続ける挙動をします。 BufferedImage image = ImageIO.read(new URL(url).openStream()); Javadocをみると以下の通り。 Opens a connection to this URL and returns an InputStream for reading from that connection. This method is a shorthand for: openConnection().getInputStream()実際、jdk1.6u18のソースを見るとopenConnection()してすぐにgetInputStream()しています。 public final InputStream ope
Google Readerは今も大量のフィードを読む人を想定してない - 半径5メートル
「Google Readerの検索が便利そう」みたいな事を書いたのですが、実際に運用し始めてみるとなかなか厳しいものを感じています。 それはGoogle Readerは未読記事1000件以上になると「1000+」という表示になるように、登録フィード数だけで1000を超えるようなユーザは想定していないためです。 未読のフィードを読むのはLDRで、検索用にGoogle Readerという感じにしようとすると、2、3日でGoogle Readerの未読はかなり溜まりますが、これを「全て読んだ事」する作業だけでもGoogle ReaderのJSが数十秒FirefoxだけでなくPCのCPU*1までも占有したりします*2。 あと、Google Readerを開いた状態でいるとAjaxで定期的に新着の未読が反映されますが、未読が溜まってくるとこの更新処理もCPU占有して他の作業をジャマしたりとか。 それ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
