GenServerビヘイビアの実装
GenServerを実装し、状態と同期・非同期の呼び出しを管理する方法を学びます。これは多くのErlangコンポーネントの基盤となります。
「GenServerビヘイビアの実装」はCoddyKit上の無料Erlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンです。 これはレッスン2/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはErlang OTP: Distributed & Fault-Tolerant Systems Programming学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースには全4レッスンが含まれています。
このレッスンの一部はまだ翻訳されておらず、英語で表示されています。
What is a GenServer?
Welcome back! In the previous lesson, we learned about Erlang's OTP behaviors. One of the most important is the GenServer.
- A GenServer is a generic server that handles requests.
- It manages internal state and processes messages in a sequential manner.
- Think of it as a standardized way to build reliable, fault-tolerant server processes in Erlang.
It's the foundation for many Erlang applications.
GenServer's Core: Callbacks
To implement a GenServer, you define a module that exports specific callback functions. These functions are called by the gen_server behavior at different stages.
init/1: Initializes the server's state.handle_call/3: Handles synchronous client requests (expects a reply).handle_cast/2: Handles asynchronous client requests (fire-and-forget).terminate/2: Cleans up when the server stops.code_change/3: Handles hot code upgrades.
We'll focus on init, handle_call, and handle_cast in this lesson.
Initializing State with `init/1`
Every GenServer starts by initializing its state. This is done in the init/1 callback function.
It takes one argument (typically a list of arguments passed during startup) and should return {ok, State}, where State is the initial data your GenServer will manage.
Here's a basic init function:
-module(my_counter).
-behaviour(gen_server).
-export([init/1]).
init([]) ->
io:format("Counter initialized with state 0.~n"),
{ok, 0}.Starting a GenServer Process
To get our GenServer running, we need to start it. The common way is using gen_server:start_link/3 or gen_server:start_link/4. We'll add a start_link/0 function to our module.
The start_link function creates a new Erlang process and links it to the calling process, making it part of a supervision tree (more on this later!).
-module(my_counter).
-behaviour(gen_server).
-export([start_link/0, init/1]).
start_link() ->
gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).
init([]) ->
io:format("Counter process started!~n"),
{ok, 0}.Synchronous Calls: `handle_call`
When a client needs a reply from the server, it makes a synchronous call using gen_server:call/2 or gen_server:call/3.
The GenServer handles these requests in its handle_call/3 callback. This function takes three arguments:
Request: The message from the client.From: The sender's process ID (Pid) and a tag.State: The current internal state of the GenServer.
It typically returns {reply, Reply, NewState}.
Implementing `handle_call` (Counter)
Let's add an increment function to our counter. This will be a synchronous call, meaning the client waits for the new count.
Try running this code. First, compile it (`c(my_counter).`), then start it (`my_counter:start_link().`). You can then call `my_counter:increment().` to see the counter increase.
-module(my_counter).
-behaviour(gen_server).
-export([start_link/0, increment/0, get_count/0]).
-export([init/1, handle_call/3, handle_cast/2, terminate/2, code_change/3]).
start_link() ->
gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).
increment() ->
gen_server:call(?MODULE, increment).
get_count() ->
gen_server:call(?MODULE, get_count).
init([]) ->
{ok, 0}.
handle_call(increment, _From, State) ->
NewState = State + 1,
{reply, NewState, NewState};
handle_call(get_count, _From, State) ->
{reply, State, State};
handle_call(_Request, _From, State) ->
{reply, {error, bad_request}, State}.
handle_cast(_Msg, State) -> % Placeholder
{noreply, State}.
terminate(_Reason, _State) -> ok.
code_change(_OldVsn, State, _Extra) -> {ok, State}.Asynchronous Calls: `handle_cast`
Sometimes, a client doesn't need a reply and just wants to send a message without waiting. This is an asynchronous call using gen_server:cast/2.
The GenServer handles these messages in its handle_cast/2 callback. It takes two arguments:
Message: The message from the client.State: The current internal state of the GenServer.
It always returns {noreply, NewState} because no reply is sent back to the client.
Implementing `handle_cast` (Reset)
Let's add a reset function to our counter. This will be an asynchronous call, as the client doesn't need to know the new count immediately.
Compile and start the module as before. Call `my_counter:increment().` a few times, then `my_counter:reset().`. You'll notice `reset` returns immediately without a value.
-module(my_counter).
-behaviour(gen_server).
-export([start_link/0, increment/0, get_count/0, reset/0]).
-export([init/1, handle_call/3, handle_cast/2, terminate/2, code_change/3]).
start_link() ->
gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).
increment() ->
gen_server:call(?MODULE, increment).
get_count() ->
gen_server:call(?MODULE, get_count).
reset() ->
gen_server:cast(?MODULE, reset).
init([]) ->
{ok, 0}.
handle_call(increment, _From, State) ->
NewState = State + 1,
{reply, NewState, NewState};
handle_call(get_count, _From, State) ->
{reply, State, State};
handle_call(_Request, _From, State) ->
{reply, {error, bad_request}, State}.
handle_cast(reset, _State) ->
{noreply, 0};
handle_cast(_Msg, State) ->
{noreply, State}.
terminate(_Reason, _State) -> ok.
code_change(_OldVsn, State, _Extra) -> {ok, State}.GenServer State Management
The power of GenServers lies in how they manage state. The State argument is passed into each callback, and the callback returns a NewState.
- This ensures that only one process (the GenServer itself) ever modifies its state, preventing race conditions.
- It makes the server's internal logic easier to reason about.
- The state can be any Erlang term: an integer, a list, a map, a record, or a complex data structure.
This sequential processing of messages and explicit state passing is key to Erlang's concurrency model.
GenServer Call Types
Which of the following statements about GenServer calls are TRUE?
Recap: Implementing GenServer
You've successfully built your first GenServer! Here's what we covered:
- GenServers are standard OTP behaviors for building stateful servers.
- The
init/1callback initializes the server's state. gen_server:start_linkcreates the GenServer process.handle_call/3handles synchronous requests (client waits for reply).handle_cast/2handles asynchronous messages (client doesn't wait).- GenServers manage their state by passing it between callbacks, ensuring sequential updates.
Next, we'll see how supervisors can automatically restart failed GenServers!
よくある質問
「GenServerビヘイビアの実装」レッスンは無料ですか？
はい。「GenServerビヘイビアの実装」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースには全4レッスンが含まれています。
「GenServerビヘイビアの実装」で何を学びますか？
GenServerを実装し、状態と同期・非同期の呼び出しを管理する方法を学びます。これは多くのErlangコンポーネントの基盤となります。 ブラウザで直接実行するハンズオンコードでErlang OTP: Distributed & Fault-Tolerant Systems Programmingを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
Erlang OTP: Distributed & Fault-Tolerant Systems Programmingを始めるのに経験は必要ですか？
事前経験は必要ありません。CoddyKitのErlang OTP: Distributed & Fault-Tolerant Systems Programmingは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン2/4です。
「GenServerビヘイビアの実装」レッスンにはどのくらい時間がかかりますか？
ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このErlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンでコードを書いて実行できますか？
はい。すべてのErlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- OTPとビヘイビアを理解する
- GenServerビヘイビアの実装
- Supervisor入門
- OTPアプリケーションとリリースの構築